SAP Planungskonzepte DE PDF

© 2019 SAP SE oder ein SAP-Konzernunternehmen Alle Rechte vorbehalten.
2017-07-31
PUBLIC (ÖFFENTLICH)
Planungskonzepte
THE BEST RUN

Inhalt
1 Planungskonzepte. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1 Konzepte zum Schutz von Daten gegen Änderungen. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.2 Datenbasis InfoProvider. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
Merkmalsbeziehungen. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9
Merkmalsbeziehungen für Zeitmerkmale. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
Datenscheiben. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .15
Merkmalsbeziehungen und Datenscheiben auf der SAP HANA-Datenbank implementieren
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
1.3 Aggregationsebene. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .23
Einfache Aggregationsebene. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
Komplexe Aggregationsebene. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
1.4 Filter. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
1.5 Variable. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
1.6 Planungsfunktionen. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
Ablauf einer Planungsfunktion: Verteilung nach Schlüsseln. . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
Standard-Planungsfunktionstypen. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .41
Standardstichtag in Planungsfunktionen. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
1.7 Planungssequenz. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
Planungssequenz in Prozesskette einplanen. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
Planungssequenz für Bottom-Up-Planung. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107
1.8 Planungsfunktionstyp implementieren. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109
Business-Logik für Planungsfunktionstyp in ABAP-Klasse implementieren. . . . . . . . . . . . . . . . . 111
Business-Logik für Planungsfunktionstyp auf der SAP HANA-Datenbank implementieren. . . . . . 115
1.9 Eingabebereite Query. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .121
Eingabebereite Queries zur Ausführungszeit. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122
Alle gültigen Merkmalskombinationen anzeigen. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123
Disaggregation (Top-Down-Verteilung). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125
Inverse Formel definieren. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135
Inverse Formel zur Laufzeit. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144
Stammdatenplanung. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 156
1.10 Sichern geänderter Werte. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .157
1.11 Audit. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159
Audit-Merkmale. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160
Audit-Query. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162
1.12 Sperrkonzept und Sperrverwaltung. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166
Verwalten der Sperreinstellungen. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168
Planungskonzepte
2 PUBLIC (ÖFFENTLICH) Inhalt
Ablegen der Sperrtabelle. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169
Auswahl der Sperrmerkmale. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171
Anzeige der aktiven Sperren. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172
Anzeige der Privilegsperren. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173
Analyse eines Sperrkonfliktes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175
Sizing der Sperrtabelle. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175
2 Planungsrelevante Objekte anlegen. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 178

2.1 Aggregationsebene anlegen. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 178
2.2 Datenscheibe anlegen. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 180
2.3 Merkmalsbeziehung anlegen. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182
Registerkarte General Settings. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 184
Registerkarte Characteristic Relations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 184
2.4 Planungsfunktion anlegen. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187
2.5 Planungssequenz anlegen. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 188
Planungskonzepte
Inhalt PUBLIC (ÖFFENTLICH) 3
1 Planungskonzepte
Die Planung in SAP Business Planning and Consolidation, version for SAP BW/4HANA, (Embedded-
Konfiguration) stellt dem Business Experten eine Infrastruktur für die Realisierung und den Betrieb von
Planungsszenarien oder anderen Applikationen zur Verfügung. Planung umfasst in diesem Sinne ein weites
Spektrum von der einfachen Dateneingabe bis hin zu komplexen Planungsszenarien.
Voraussetzungen
Für die Planung benötigt der Benutzer grundsätzlich dieselben Berechtigungen wie für die Analyse von Daten in
einer Query. Zusätzlich wird in den Analyseberechtigungen neben der Berechtigung für das Anzeigen von
Daten auch die Berechtigung für das Ändern von Daten benötigt.
Kontext
Das Planungsmodell umfasst folgende Elemente:
● Daten (abgelegt in für Planung geeigneten InfoProvidern)

● Einschränkungen auf Daten oder deren Eingabebereitschaft (CompositeProvider, Merkmalsbeziehungen)
● Methoden zur Veränderung von Daten (Planungsfunktionen, Planungssequenzen - auch innerhalb von
Prozessketten, manuelle Planung in Form eingabebereiter Queries)
● Hilfsmittel (Filter, die in Queries und Planungsfunktionen verwendet werden können; Variablen zur
Parametrisierung der Objekte, die in der Regel mindestens überall dort verwendet werden können, wo
Selektionen eine Rolle spielen, also z.B. auch in Datenscheiben)
● Konzepte zum (ggf. zeitlich begrenzten) zentralen Schutz von Daten (Datenscheiben)
Vorgehensweise
1. Datenbasis anlegen und Sperren verwalten
Zur Ablage der Daten werden für die Planung geeignete InfoProvider verwendet.
Damit stets nur ein Benutzer Daten ändern kann, werden "dessen" Daten gegen fremde Änderungen
gesperrt. Je nach zu erwartender Last (determiniert durch die Anzahl paralleler Benutzer und durch die
Komplexität der Selektion) kann ein bestimmtes von mehreren angebotenen Sperrverfahren voreingestellt
werden.
2. Objekte des Planungsmodells definieren
○ Aggregationsebenen
Um die Ebene festzulegen, auf der Daten (manuell durch Benutzereingabe oder automatisch per
Planungsfunktion) erfasst bzw. geändert werden können, wird ein InfoProvider vom Typ einer
Planungskonzepte
4 PUBLIC (ÖFFENTLICH) Planungskonzepte
Aggregationsebene definiert. Eine Aggregationsebene besteht aus einer Untermenge von Merkmalen
und Kennzahlen eines für die Planung geeigneten InfoProviders.
○ Merkmalsbeziehungen
Über Merkmalsbeziehungen können semantische Beziehungen zwischen Merkmalen (wie Produkt -
Produktgruppe) modelliert werden. Hierüber wird z.B. gesteuert, ob eine bestimmte
Merkmalskombination erzeugt werden kann (also erlaubt ist), oder ob eine Zelle eingabebereit ist.
Merkmalsbeziehungen werden zu einem für die Planung geeigneten InfoProvider angelegt.
○ Datenscheiben
Über eine Datenscheibe können bestimmte Bereiche der Daten global gegen Änderungen geschützt
werden (z.B. Ist-Werte oder historische Werte).
○ Planungsfunktionen
Planungsfunktionen dienen zur systemgestützten Bearbeitung bzw. Erzeugung von Daten. Funktionen
können unmittelbar (über Drucktaste) oder im Hintergrund als Planungssequenz ausgeführt werden.
SAP liefert zahlreiche Standard-Planungsfunktionstypen aus. Zusätzlich können Sie auch eigene
Funktionstypen definieren.
○ Planungssequenzen
Eine Planungssequenz ist eine Abfolge von Planungsfunktionen und manuellen Eingabemasken, die
nacheinander ausgeführt werden. Planungssequenzen können auch zur Verarbeitung im Hintergrund
als Schritt einer Prozesskette eingeplant werden.
○ Filter
Ein Filter beschreibt einen Ausschnitt des Datenbestandes, der z.B. in einer Query oder in einer
Planungsfunktion bearbeitet wird (z.B.: Kalenderjahr 2016 - 2017; Kundengruppe XY).
○ Variablen
Sie können Variablen an verschiedenen Stellen einsetzen: im Filter zur parametrisierbaren Selektion
von Merkmalswerten, zur Parametrisierung von Planungsfunktionen oder Planungssequenzen.
 Hinweis
Informationen über den Transport der Objekte des Planungsmodells finden Sie unter .
3. Eingabebereite Query definieren
In den BW-Modellierungswerkzeugen können Sie eine Query definieren, die auf einem für die Planung
geeigneten InfoProvider beruht und eingabebereit ist. Eine solche Query kann zur manuellen Planung
verwendet werden. Ob eine bestimmte Zelle eingabebereit ist, hängt vom Aufriss ab und davon, ob sie
entsprechend den Merkmalsbeziehungen und Datenscheiben erlaubt ist.
Weitere Informationen
Datenbasis InfoProvider [Seite 7]

Aggregationsebene [Seite 23]
Filter [Seite 28]
Variable [Seite 30]
Planungsfunktionen [Seite 33]
Planungssequenz [Seite 99]
Planungsfunktionstyp implementieren [Seite 109]
Eingabebereite Query [Seite 121]
Planungskonzepte
Planungskonzepte PUBLIC (ÖFFENTLICH) 5
Sichern geänderter Werte [Seite 157]
Audit [Seite 159]
Sperrkonzept und Sperrverwaltung [Seite 166]
1.1 Konzepte zum Schutz von Daten gegen Änderungen
Als Teil des Planungsmodells gibt es auf verschiedene Anwendungsfälle zugeschnittene Konzepte zum Schutz
vor Datenänderungen.
In der Regel verwendet man für die Planung verschiedene Versionen, die nach Abschluss der Planung nicht
mehr geändert werden dürfen. Ein anderer Anwendungsfall ist die rollierende Planung, in der ein gewisses
Zeitfenster für die Planung geöffnet wird. So sind z.B. die nächsten 12 Monate nach dem aktuellen Monat für
die Planung geöffnet, alle Monate bis zum aktuellen Monat sind geschlossen. Diesen Anwendungsfällen
gemeinsam ist, dass i.a. der Schutz der Plandaten von Änderungen für alle Anwender (ggf. außer
Administratoren) gilt. Diese Anwendungsfälle können Sie durch Datenscheiben abbilden. Datenscheiben
wirken i.a. unabhängig vom Anwender für die manuelle Planung und für Planungsfunktionen. Durch die
Verwendung von Variablen oder Exit-Datenscheiben kann man auch erreichen, dass Datenscheiben abhängig
vom Anwender gesetzt werden.
Mit Datenscheiben ist ansatzweise eine Statusverwaltung der Planung möglich. Diese wird jedoch nicht
explizit vom System unterstützt, da eine Statusverwaltung der Plandaten i.a. die gesamte Planung in
Verantwortungsbereiche aufteilt und die Personen zuordnet, welche die Planung steuern, überwachen und den
Status der Planung verwalten. Dazu werden in der Regel Merkmale ermittelt, über die sich die
Verantwortungsbereiche abgrenzen lassen. Für eine Kostenstellenplanung kann das die Kostenstelle sein, für
eine Vertriebsplanung die Merkmale Land, Region. Dieser Anwendungsfall wird vom System durch die Nutzung
des Arbeitsstatus im SAP Business Planning and Consolidation, version for SAP BW/4HANA, (Embedded-
Konfiguration) unterstützt. Der Arbeitsstatus ermöglicht es, die Verantwortungsbereiche zu definieren und
verantwortlichen Personen zuzuordnen. Für die verschiedenen Bereiche und Teilbereiche kann ein frei
definierbarer Planstatus gesetzt werden; darüber lassen sich insbesondere auch Plandaten gegen Änderungen
schützen. Diese Funktionalität wird im Rahmen der Arbeitsstatusverwaltung zur Verfügung gestellt. Für die
Umsetzung des Schutzes vor Datenänderungen – je nach Status der Plandaten - werden vom System zur
Laufzeit erzeugte Datenscheiben verwendet.
Neben den Konzepten der Datenscheiben und der Arbeitsstatusverwaltung des SAP Business Planning and
Consolidation, version for SAP BW/4HANA, (Embedded-Konfiguration), die in der Datenbank abgelegt werden,
gibt es das Konzept der Fixierung von Zellwerten in der manuellen Planung. Diese Fixierung von Zellwerten ist
eine Eingabehilfe, um interaktiv z.B. in der Disaggregation einige Werte von der Verteilung auszunehmen oder
die Reihenfolge der Berechnungen von inversen Formeln zu steuern. Fixierungen sind nur in der Benutzer-
Session gültig und werden nicht in der Datenbank abgelegt.
Völlig unabhängig von den oben genannten drei Konzepten ist das Sperrkonzept der Planung in SAP Business
Planning and Consolidation, version for SAP BW/4HANA, (Embedded-Konfiguration), welches alle im
Änderungsmodus gelesenen Bewegungsdaten exklusiv für die Bearbeitung in einer Benutzer-Session sperrt.
Dieses Sperrkonzept stellt sicher, dass nur derjenige Benutzer die gesperrten Daten verändern kann, der die
exklusive Sperre hält.
Planungskonzepte
Datenscheiben [Seite 15]

Sperrkonzept und Sperrverwaltung [Seite 166]
1.2 Datenbasis InfoProvider
Als Datenbasis dienen InfoProvider, die für die Planung geeignet sind oder die solche InfoProvider enthalten.
Für die Planung geeignete Basis-InfoProvider
In den für die Planung geeignete Basis-InfoProvider werden die Daten persistiert. Dafür stehen Ihnen
folgende InfoProvider zur Verfügung:
● DataStore-Objekte:
○ Standard DataStore-Objekt mit der Eigenschaft Write Change Log
○ DataMart DataStore-Objekt
○ Direct Update DataStore-Objekt
 Hinweis
Weitere Informationen über Planung auf einem DataStore-Objekt finden Sie im SAP-Hinweis 2189829
.
● InfoObject (Merkmal):
○ mit der Modellierungseigenschaft Usable as InfoProvider
○ mit der Modellierungseigenschaft Planning Mode
○ als InfoProvider befindet es sich im Planning Mode (Standardmäßig befindet sich ein beplanbares
InfoObject zunächst im Load Mode und muss umgeschaltet werden.)
 Hinweis
Weitere Informationen über die allgemeinen Einstellungen am InfoObject finden Sie unter sowie über
die Möglichkeit, zwischen Load und Planning Mode umzuschalten, unter .
Beachten Sie weiterhin folgende Bedingungen, die erfüllt sein müssen, damit ein Merkmal als Basis-
InfoProvider für die Stammdatenplanung benutzt werden kann:
○ Das Merkmal hat eine Stammdatentabelle und ist mit Mitteln des SAP BW∕4HANA angelegt worden,
d.h. es wurde nicht mittels einer speziellen Stammdatenleseklasse implementiert wie z.B. SAP-HANA-
Views.
○ Es besitzt nicht die Eigenschaft Erweiterte Stammfortschreibung (Enhanced Master Data Update).
○ Es ist kein XXL-InfoObject.
○ Das Merkmal ist keine Referenz auf ein anderes Merkmal.
Falls das InfoObject einen Text mit der Eigenschaft Long Text is Extra Long oder die Eigenschaft Attribute
Only hat, so kann dieser Text nicht beplant werden.
Planungskonzepte
● Lokaler Provider im BW Workspace
Es gilt damit allgemein die Regel, dass Datensätze über die Planung nur dann verändert werden können,
wenn auf dem Weg von ‚oben‘ nach ‚unten‘ zum planbaren Basis-InfoProvider genau eine
Aggregationsebene beteiligt ist.
Für die Planung geeignete CompositeProvider
Die Planung erfolgt nicht direkt auf den oben genannten Basis-InfoProvidern, sondern über einen InfoProvider
vom Typ Aggregationsebene, der definiert, welche Merkmale und Kennzahlen in Datensätzen gefüllt werden
können.
Aggregationsebenen können auf planbaren Basis-InfoProvidern definiert werden oder auf zusammengesetzten
InfoProvidern, sofern diese nicht schon Aggregationsebenen enthalten.
Folgende zusammengesetzte InfoProvider sind als Basis für Aggregationsebenen geeignet:
● CompositeProvider, die mindestens einen für die Planung geeigneten Basis-InfoProvider enthalten. Die
beteiligten InfoProvider (incl. von SAP-HANA-Modellen) dürfen dabei nur über eine UNION verknüpft sein.
 Hinweis
Weitere Informationen über Planung auf einem CompositeProvider finden Sie im SAP-Hinweis 2091885
.
● Beachten Sie, dass 1KYF_* Kennzahlen eines Basis-InfoObjects nur dann im CompositeProvider gemappt
werden dürfen, wenn sie zu einem Navigationsattribut des InfoObjects gehören. Insbesondere können die
Datumsfelder 1KYF_DATE*, 1KYF_TXTDATE* sowie die 1KYF-Kennzahlen zu Einheiten und Währungen
nicht im CompositeProvider exponiert werden.
Ein CompositeProvider kann direkt für die Planung verwendet werden, wenn dieser mindestens eine
Aggregationsebene enthält.
Merkmalsbeziehungen und Datenscheiben
Im Rahmen der Planung können Sie zu einem für die Planung geeigneten Basis-InfoProvider zulässige
Kombinationen von Merkmalswerten in Form von Merkmalsbeziehungen definieren und zum Schutz
ausgewählter Daten Datenscheiben anlegen.
 Achtung
Beachten Sie, dass Änderungen für Zentrale Einstellungen, Merkmalsbeziehungen und Datenscheiben in der
aktiven Benutzer-Sessions i.a. nicht sofort wirksam werden, wenn diese Einstellungen in eben dieser
Benutzer-Session schon gelesen wurden: Diese Einstellungen sind aus Konsistenz- und Performance-
Gründen gepuffert.
Für den Fall, dass die generischen Typen der Merkmalsbeziehungen (Attribut, Hierarchie) und der
Datenscheiben (Selektion) für die individuellen Kundenanforderungen nicht ausreichen, können Sie
Merkmalsbeziehungen und Datenscheiben vom Typ Exit implementieren.
Planungskonzepte
Standardstichtag für die Planung
Weiterhin können Sie zu einem für die Planung geeigneten InfoProvider einen Stichtag als Standardstichtag für
die Planung festlegen. Wenn zeitabhängige Objekte, etwa Attribute oder Hierarchien, in Objekten des
Planungsmodells verwendet werden, kann man sich dort stets auch auf den Standardstichtag für die Planung
beziehen. So können Sie sicherstellen, dass im Planungsmodell ein einheitlicher Stichtag verwendet wird. Die
hierfür relevanten Objekte des Planungsmodells sind Merkmalsbeziehungen, Datenscheiben und Parameter
von Planungsfunktionen.
Werkzeuge
InfoProvider als Datenbasis für die Planung legen Sie in den BW-Modellierungswerkzeugen oder als Local Query
extended Model an.
Diese Links führen in die Dokumentation der für die Planung geeigneten Basis-InfoProvider.
Aggregationsebene anlegen [Seite 178]
Diese Links führen in die Dokumentation der für die Planung geeigneten CompositeProvider sowie der
Aggregationsebene.
Merkmalsbeziehungen [Seite 9]
Merkmalsbeziehungen und Datenscheiben auf der SAP HANA-Datenbank implementieren [Seite 16]
Datenscheiben [Seite 15]
Standardstichtag in Planungsfunktionen [Seite 98]
Stammdatenplanung [Seite 156]
Diese Links führen in die Dokumentation planungsspezifischer Metadatenobjekte und zentraler Einstellungen.
1.2.1 Merkmalsbeziehungen
Merkmalsbeziehungen dienen dazu, inhaltlich korrespondierende Merkmale miteinander in Beziehung zu

setzen.
Verwendung
Mit Hilfe von Merkmalsbeziehungen können Sie Regeln definieren, um zulässige Kombinationen von
Merkmalswerten für jeden für die Planung geeigneten Basis-InfoProvider zu überprüfen. Außerdem können Sie
Regeln definieren, nach denen das System aus Merkmalen Werte für weitere Merkmale ableiten kann. Dies ist
dann sinnvoll, wenn z.B. die ableitbaren Merkmale für weitere Auswertungen zur Verfügung stehen sollen.
Planungskonzepte
Sie können Merkmalsbeziehungen zu den Stammdaten eines Merkmals (Typ Attribut), einer Hierarchie (Typ
Hierarchie), einem DataStore-Objekt (Typ DataStore) oder einer Exit-Klasse (Typ Exit) definieren.
Ein InfoProvider kann entweder als Ablage für Transaktionsdaten für die Planung oder zur Modellierung der
zulässigen Merkmalskombination verwendet werden.
 Tipp
Wenn Sie zur Ablage der zulässigen Merkmalskombinationen ein Direct Update DataStore-Objekt
verwenden, hat das den Vorteil, dass man dieses DataStore-Objekt direkt mit einer eingabebereiten Query
pflegen kann.
Wir empfehlen, die Rollen der InfoProvider für die Ablage der Plandaten und für die Ablage der Regeln für die
Plandaten nicht zu vermischen. Falls dies in einer Benutzersitzung dennoch geschieht, gelten die folgenden
Regeln:
● Wenn ein InfoProvider namens A zuerst als InfoProvider für die Planung genutzt wird, sind andere
InfoProvider, die A in einer Merkmalsbeziehung verwenden, nicht eingabebereit.
● Wenn der InfoProvider A zuerst in einer Merkmalsbeziehung und anschließend als InfoProvider für die
Planung verwendet wird, dann ist der Planungsprovider nicht eingabebereit.
● Wenn der InfoProvider A in einem CompositeProvider gleichzeitig als PartProvider sowie in einer
Merkmalsbeziehung eines anderen PartProviders verwendet wird, dann ist der PartProvider A nicht
eingabebereit.
Integration
Wenn Merkmalsbeziehungen in bezug auf Attribute und Hierarchien zu Merkmalen definiert werden, stellt das
System diejenigen Attribute und Hierarchien zur Auswahl, die im jeweiligen System zu einem Merkmal angelegt
wurden.
Merkmalsbeziehungen werden zu einem für die Planung geeigneten Basis-InfoProvider angelegt. Sie wirken
sich dann in allen für die Planung relevanten InfoProvidern aus, die diesen Basis-InfoProvider referenzieren.
Jede eingabebereite Query und jede Planungsfunktion berücksichtigt damit automatisch die
Merkmalsbeziehungen:
● In einer eingabebereiten Query sind Zellen zu ungültigen Merkmalskombinationen nicht eingabebereit, und
neue Datensätze mit ungültigen Merkmalskombinationen können nicht erzeugt werden.
● Planungsfunktionen überprüfen stets, ob neue Merkmalskombinationen entsprechend den
Merkmalsbeziehungen gültig sind. Im Fall von ungültigen Kombinationen teilt das System dies durch eine
Fehlermeldung mit.
Die möglichen Merkmalsableitungen finden bei der Ermittlung der Delta-Sätze im Delta-Buffer (für den lokalen
Provider im BW Workspace) oder im After-Image-Buffer (für das DataStore-Objekt) statt.
Die möglichen Quellmerkmale sind hier die Merkmale des planungsrelevanten InfoProviders, die von
Merkmalen aus den beteiligten Aggregationsebenen gefüllt werden. Wenn Merkmalsbeziehungen geändert
werden, müssen ggf. Datensätze im planungsrelevanten InfoProvider auf die neue Struktur angepasst werden.
Hierzu dient die Planungsfunktion Umbuchen Merkmalsbeziehungen.
Planungskonzepte
Voraussetzungen
Um Merkmalsbeziehungen definieren zu können, müssen folgende Voraussetzungen erfüllt sein:
● Der InfoProvider muss ein für die Planung geeigneter Basis-InfoProvider sein. Die definierten
Merkmalsbeziehungen sind auch in CompositeProvidern wirksam, in denen die planungsrelevanten Basis-
InfoProvider verwendet werden.
● Bei Merkmalsbeziehungen vom Typ Attribut muss das Zielmerkmal als Attribut des Basismerkmals
definiert und selbst im planungsrelevanten Basis-InfoProvider enthalten sein.
● Bei Merkmalsbeziehungen vom Typ Hierarchie muss das Zielmerkmal in der ausgewählten Hierarchie und
im planungsrelevanten Basis-InfoProvider enthalten sein. Die Hierarchie ist hauptsächlich zur Modellierung
einer Ableitungsbeziehung gedacht; daher darf die Hierarchie kein Blatt und keinen inneren Knoten
mehrfach enthalten. Link-Knoten sind ebenfalls nicht zulässig.
● Bei Merkmalsbeziehungen vom Typ DataStore sind nur die folgenden DataStore-Objekte zulässig:
○ DataStore-Objekt: Alle Typen sind unterstützt, sofern das DataStore-Objekt einen eindeutigen
Schlüssel besitzt und kein DataMart DataStore-Objekt ist.
 Hinweis
Neben den oben genannten Merkmalsbeziehungen, die Sie bearbeiten können, sind im System stets
weitere Merkmalsbeziehungen für die Zeitmerkmale aktiv.
Funktionsumfang
Definition einer Merkmalsbeziehung
Merkmalsbeziehungen können Sie zu einem für die Planung geeigneten Basis-InfoProvider anlegen. Eine
Merkmalsbeziehung besteht aus einer Menge von Relationen (Schritten), die einfach fortlaufend nummeriert
werden. Jede dieser Relationen setzt eine Menge von Merkmalen in Beziehung. Diese Relationen stellen die
kleinsten Einheiten einer Merkmalsbeziehung dar.
Verhalten bei Kombinationsprüfung ohne und mit Ableitung
Relationen können ausschließlich zur Prüfung von Merkmalskombinationen oder zusätzlich auch zu einer
Merkmalsableitung dienen. Sie legen dieses Verhalten bei der Definition einer Relation fest. Insbesondere bei
Relationen vom Typ Ableitung können Beziehungen unter Relationen dadurch hergestellt werden, dass
Zielmerkmale einer Relation Quellmerkmale einer anderen Relation sind. Dabei sollten Redundanzen
vermieden werden, damit die Relationen wirklich die kleinsten Einheiten der Merkmalsbeziehungen darstellen.
Das System ermittelt zur Laufzeit, welche Relationen der Merkmalsbeziehungen in den InfoProvidern, die für
die Planung relevant sind, zur Anwendung gelangen.
● Kombinationsprüfung: Eine Relation kommt dann in einer Aggregationsebene zur Anwendung, wenn
jedes Merkmal der Relation in der Aggregationsebene vorkommt. Bei Ableitungen sind dies die Quell- und
Zielmerkmale; in diesem Fall wird nichts abgeleitet, die Relation wirkt nur als Kombinationsprüfung.
● Merkmalsableitung: Innerhalb einer Aggregationsebene findet keine Ableitung statt. Eine Ausnahme von
dieser Regel sind neue Zeilen in eingabebereiten Queries: Dort versucht das System, aus bekannten
Merkmalswerten weitere Merkmalswerte für andere Merkmale über Ableitungen aufzufüllen. Ableitungen
erfolgen nur für Sätze des planungsrelevanten Basis-InfoProviders. Zunächst ermittelt das System die
Menge S der Merkmale, die von der beteiligten Aggregationsebene versorgt werden. Das System wendet
Planungskonzepte
dann diejenigen Ableitungsrelationen an, deren sämtliche Quellmerkmale in der Menge S enthalten sind.
Die Zielmerkmale dieser Ableitungen können dann wiederum in folgenden Schritten als Quellen dienen.
Insofern führt das System auf der Ebene des planungsrelevanten Basis-InfoProviders die maximal
mögliche Ableitung durch. Wenn bereits abgeleitete Merkmalswerte in nachfolgenden Schritten erneut
verändert werden, ist die Ableitung fehlerhaft. Das System gibt eine entsprechende Fehlermeldung aus.
Besonderheiten beim initialen Merkmalswert (# nicht zugeordnet)
Innerhalb einer Relation ist zu beachten, dass der initiale Merkmalswert (# nicht zugeordnet) eine besondere
Rolle spielt. Das hängt damit zusammen, dass Merkmale, die nicht in einer Aggregationsebene vorkommen
(und nicht ableitbar sind) mit dem Initialwert fortgeschrieben werden.
 Beispiel
● Kombinationsprüfung ohne Ableitung:

Gegeben sei eine Relation zwischen den Merkmalen Produkt und Sortiment, hier besteht im
allgemeinen keine Ableitungsbeziehung. In Aggregationsebenen mit Produkt ohne Sortiment wird
daher Sortiment mit dem Initialwert fortgeschreiben. Solche Kombinationen sind somit immer gültig;
sie können nicht verboten werden. Entsprechendes gilt für Kombinationen mit dem Initialwert für
Produkt.
● Kombinationsprüfung mit Ableitung:
Gegeben sei eine Relation zwischen den Merkmalen Kostenstelle und Profitcenter, hierbei ist
Profitcenter aus Kostenstelle ableitbar. In einer Aggregationsebene mit Profitcenter ohne Kostenstelle
wird jedoch ebenfalls die Kostenstelle mit dem Initialwert fortgeschrieben. Solche Kombinationen
können nicht verboten werden. Die Umkehrung gilt hier aber wegen der möglichen Ableitung von
Profitcenter aus Kostenstelle nicht.
Die in dem obigen Beispiel aufgeführten speziellen Kombinationen mit dem Initialwert werden automatisch
gültige Kombinationen genannt. Im Fall einer Relation vom Typ Exit werden für automatisch gültige
Kombinationen die Methoden CHECK und DERIVE nicht aufgerufen. Weiterhin erzeugt das System die
automatisch gültigen Kombinationen auch dann, wenn diese in der Methode CREATE nicht zurück gegeben
werden. Wenn dieses Verhalten in einer Merkmalsbeziehung nicht gewünscht ist, kann man dies über das
Kennzeichen Also apply to automatically valid combinations = X einstellen. In diesem Fall
werden die Methoden CHECK, DERIVE auch für automatisch gültige Kombinationen aufgerufen; weiterhin
werden die in CREATE erzeugten Kombinationen vom System nicht um die automatisch gültigen
Kombinationen ergänzt.
 Hinweis
Beachten Sie, dass Merkmalsbeziehungen nicht als ein weiterer impliziter Filter für die zu lesenden
Bewegungsdaten wirken. Das System liest die durch den Filter der Query oder Planungsfunktion
spezifizierten Bewegungsdaten (egal ob laut Merkmalsbeziehung gültig oder nicht gültig) und erzeugt dann
ggf. zusätzlich nach den oben erläuterten Regeln weitere Kombinationen.

Merkmalsbeziehungen für Zeitmerkmale [Seite 13]
Diese Links führen in die Dokumentation des Konzeptes der Merkmalsbeziehungen.
Planungskonzepte
Merkmalsbeziehung anlegen [Seite 182]
Registerkarte General Settings [Seite 184]
Registerkarte Characteristic Relations [Seite 184]
Diese Links führen in die Dokumentation der Aufgabe, wie man eine Merkmalsbeziehung bearbeitet.
1.2.2 Merkmalsbeziehungen für Zeitmerkmale

Das BW/4HANA-System enthält verschiedene Zeitmerkmale. Beim Anlegen eines Planungsmodells besteht
eine Aufgabe darin, das für den planungsrelevanten InfoProvider geeignete Zeitmerkmal auszuwählen.
Verwendung
In der Regel soll die Verwendung von redundanten Zeitmerkmalen in einem planungsrelevanten InfoProvider
vermieden werden. Das folgende Beispiel zeigt jedoch, dass dies in bestimmten Anwendungsfällen sinnvoll sein
kann.
 Beispiel
Abhängig von der jeweiligen Planungsanwendung, etwa für die Rollierende Planung, kann z.B. das Merkmal
Geschäftsjahresperiode 0FISCPER (12.2005 + 1 = 1.2006) verwendet werden.
Wenn Sie aber z.B. Query Views bauen möchten, die die Perioden in den Zeilen und das Geschäftsjahr in
den Datenspalten enthalten, ist es sinnvoller, die Zeitmerkmale Periode und Geschäftsjahr zu verwenden.
Wenn ein planungsrelevanten InfoProvider redundante Zeitmerkmale enthält, verwendet das System zur
Laufzeit die von eingabebereiten Queries oder Planungsfunktionen benötigten Merkmalsbeziehungen für die
entsprechenden Zeitmerkmale. Diese Merkmalsbeziehungen sind vom Typ "Ableitung" mit Ausnahme der
Merkmalsbeziehung für die Merkmale 0FISCVARNT, 0FISCYEAR, 0FISCPER3.
 Achtung
Beachten Sie, dass das System nur eindeutige Beziehungen zulässt. So kann aus dem Zeitmerkmal Quartal
(0CALQUARTER) das Kalenderjahr (0CALYEAR) abgeleitet werden, jedoch nicht die Kalenderwoche
(0CALWEEK).
Wenn Sie eine solche Beziehung modellieren möchten, benötigen Sie eine eigene Merkmalsbeziehung vom
Typ Exit, die eigene Merkmale verwendet, welche die geeigneten Standardzeitmerkmale referenzieren.
Das System wendet die abgeleiteten Merkmalsbeziehungen für die Zeitmerkmale (so wie bei den anderen
Relationen auch) zur Kombinationsprüfung bzw. zur Ableitung an.
 Achtung
Beachten Sie, dass es für jedes Zeitmerkmal ein im System einstellbares, maximal gültige Zeitintervall gibt.
Wenn Sie ein Zeitmerkmal verwenden, muss das maximal gültige Zeitintervall den gesamten
Planungszeitraum umfassen.
In Ihrem Backendsystem können Sie das Zeitintervall auf dem Bild F4-Hilfe und Hierarchien für
Zeitmerkmale (Transaktionscode RSRHIERARCHYVIRT) auf der Registerkarte Allgemeine Einstellungen
Planungskonzepte
festlegen. Da diese Einstellung performancerelevant ist, empfehlen wir, das Intervall so klein wie möglich zu
halten.
Es ist nicht möglich, Ableitungen anzulegen, die eine im System automatisch verwendete Zeitableitung
enthalten.
Die folgende Tabelle gibt eine Übersicht darüber, welche Ableitungen vom System automatisch unterstützt
werden:
Quellmerkmale Zielmerkmale Kommentar
0CALDAY 0CALWEEK
0CALDAY 0CALMONTH
0CALDAY 0CALQUARTER
0CALDAY 0CALYEAR
0CALDAY, 0FISCVARNT 0FISCPER Geschäftsjahresvariante wird benötigt

wegen Klammerung
0CALDAY, 0FISCVARNT 0FISCYEAR Geschäftsjahresvariante wird benötigt

wegen Klammerung
0CALDAY 0WEEKDAY1
0CALDAY 0CALMONTH2
0CALDAY 0CALQUART1
0CALDAY 0HALFYEAR1
0CALDAY, 0FISCVARNT 0FISCPER3 Geschäftsjahresvariante wird benötigt

wegen Klammerung
0CALMONTH 0CALQUARTER
0CALMONTH 0CALYEAR
0CALMONTH 0CALMONTH2
0CALMONTH 0CALQUART1
0CALMONTH 0HALFYEAR1
0CALQUARTER 0CALYEAR
0CALQUARTER 0CALQUART1
0CALQUARTER 0HALFYEAR1
0CALMONTH2 0CALQUART1
Planungskonzepte
Quellmerkmale Zielmerkmale Kommentar
0CALMONTH2 0HALFYEAR1
0CALQUART1 0HALFYEAR1
0FISCPER, 0FISCVARNT 0FISCYEAR Geschäftsjahresvariante wird benötigt

wegen Klammerung
0FISCPER, 0FISCVARNT 0FISCPER3 Geschäftsjahresvariante wird benötigt

wegen Klammerung
0CALWEEK, 0WEEKDAY1 0CALDAY
0CALYEAR, 0CALQUART1 0CALQUARTER
0CALYEAR, 0CALMONTH2 0CALMONTH
0FISCYEAR, 0FISCVARNT, 0FISCPER3 0FISCPER Geschäftsjahresvariante wird benötigt

wegen Klammerung
0FISCVARNT, 0FISCYEAR, 0FISCPER3 Geschäftsjahresvariante wird benötigt

wegen Klammerung
1.2.3 Datenscheiben
Datenscheiben sind ein Konzept, um zentral Daten eines planungsrelevanten Basis-InfoProviders gegen
Änderungen zu schützen. Dieser Schutz wirkt sich auf alle eingabebereiten Queries und Planungsfunktionen
aus, die diesen planungsrelevanten InfoProvider verwenden.
Funktionsumfang
Es gibt zwei Typen von Datenscheiben:
● Die Datenscheibe basiert auf einer Selektion. Hier legen Sie die Einschränkungen für die Merkmale fest,
die Sie gegen Änderungen schützen möchten.
● Die Datenscheibe basiert auf einer Exit-Klasse. In der Exit-Klasse können Sie eine kundenspezifische Logik
zum Schutz von Datensätzen implementieren. Beachten Sie dort auch die Dokumentation zu den
Attributen und Methoden der Klasse in der Transkation SE24. Wenn Sie Zugriffe auf die bereits gelesenen
Datensätze in der Methode IS_PROTECTED puffern möchten, können Sie diese Aufgabe dem System
Planungskonzepte
übertragen und müssen dies nicht im Exit implementieren. Dazu setzen Sie im CONSTRUCTOR der Exit-
Klasse das Attribut N_USE_EXTERNAL_BUFFER im Interface IF_RSPLS_DATASLICE.
Grundsätzlich gelten für Datenscheiben die folgenden Regeln:
● Wenn für einen planungsrelevanten Basis-InfoProvider keine Datenscheibe definiert ist, können in diesen
InfoProvider beliebige gültige Merkmalswertkombinationen gebucht werden.
● Jeder Datensatz, der in die Selektion einer Datenscheibe fällt, ist gegen Änderungen geschützt.
Entsprechende Zellen in eingabebereiten Queries sind nicht änderbar; über Planungsfunktionen können
solche Sätze nicht verändert und gesichert werden. Die Datenscheiben addieren sich in ihrer Wirkung.
● Wenn ein planungsrelevanter Basis-InfoProvider eine Datenscheibe enthält, die keine
Merkmalswerteinschränkungen enthält, wirkt die Datenscheibe als Sperre für Buchungen aller Art im
gesamten InfoProvider.
● Wenn Sie eine neue Datenscheibe sichern, so hat diese Datenscheibe den Status Aktiv.
● Sie können eine vorhandene Datenscheibe deaktivieren, z.B. in dem Fall, dass zur Administration von
Daten auch Daten geändert werden müssen, die in einer vorhandenen Datenscheibe liegen. Setzen Sie in
diesem Fall das Kennzeichen Aktiv zurück.
Datenscheibe anlegen [Seite 180]
1.2.4 Merkmalsbeziehungen und Datenscheiben auf der SAP

HANA-Datenbank implementieren
Für den Fall, dass die generischen Typen der Merkmalsbeziehungen (Attribut, Hierarchie, DataStore) und der
Datenscheiben (Selektion) für die individuellen Kundenanforderungen nicht ausreichen, können Sie
Merkmalsbeziehungen und Datenscheiben vom Typ Exit implementieren.
Anforderungen, die mit einer Implementierung von Merkmalsbeziehungen oder Datenscheiben vom Typ Exit
erfüllt werden können, sollen durch die beiden folgenden Beispiele veranschaulicht werden:
● Beispiel 1: Wir nehmen an, dass zwei bisher getrennte Vertriebsorganisationen zusammengeschlossen
werden. Beide haben ein sich überschneidendes Produktangebot mit ursprünglich unabhängigen
Produktnummern. Um eine einheitliche Berichterstattung über das gesamte Produktangebot zu
ermöglichen, werden die beiden unabhängigen Produktkataloge über eine Mappingtabelle einem
übergreifenden Produktkatalog zugeordnet. Die Mappingtabelle hat folgende Struktur:
Mappingtabelle Z_MAP_PRODUCT
Region Regional_Prod_ID Produkt_ID
R_01 RP_123 UP_123
R_02 RP_123 UP_321
... ...
In den regional verschiedenen Vertriebsorganisationen können verschiedene Produkte dieselbe

Identifikationsnummer haben. Damit es bei einem überregionalen Vergleich eine eindeutige Bezeichnung
Planungskonzepte
gibt, müssen diese RP-Nummern in eindeutige UP-Nummern umgewandelt werden. In unserem Beispiel
erhält das Produkt RP_123 aus der Region R_02 die Produkt-ID UP_321.
● Beispiel 2: Wir nehmen an, dass ein unternehmensweiter Planungsprozess für Vertriebskennzahlen pro
Kalenderquartal auf der Ebene der Produktgruppen aufgesetzt werden soll. Hierbei ist zu berücksichtigen,
dass einige regionale Vertriebsorganisationen ihre Plandaten (zumindest für bestimmte Planversionen) ab
einem definierten Zeitpunkt festschreiben, während andere ihre Plandaten anpassen können, wenn
bestimmte Ereignisse solche späten Anpassungen erfordern.
Unter diesen Umständen können z.B. die Plandaten einer Region A für das erste Quartal des folgenden
Jahres nach dem 15. Dezember des laufenden Jahres festgeschrieben werden, während einer Region B
erlaubt wird, ihren Plan einer sich unerwartet ergebenden Gelegenheit eines zusätzlichen Umsatzes sogar
bis zum Ende des Monats Januar des folgenden Jahres anzupassen. Um dies nachvollziehbar zu machen,
kann man eine Planversion V2 einführen, diese neue Planversion mit den ursprünglichen Plandaten aus
Planversion V1 füllen und dann diese Planversion für Anpassungen allein der Region B öffnen.
Um die Anforderung aus Beispiel 1 zu implementieren, kann man eine Merkmalsbeziehung vom Typ Exit
definieren, die zwei Relationen (Schritte) mit Ableitung enthält: Die erste Relation hat die eindeutige ID als
Quell- und die ursprüngliche ID (in Verbindung mit der ursprünglichen Vertriebsorganisation) als Zielmerkmal;
die zweite genau umgekehrt. Somit wird die ursprüngliche ID abgeleitet, wenn auf der eindeutigen ID geplant
wird. Die eindeutige ID wird abgeleitet, wenn die Felder umgedreht werden. Konsistenz der beiden IDs wird
sichergestellt, wenn beide Merkmale für Planung offen sind.
Die Anforderung aus Beispiel 2 ist ein typischer Fall für eine Datenscheibe vom Typ Exit, definiert auf den
Merkmalen Region, Planversion und Quartal, mit Zugriff auf Daten, die außerhalb des SAP BW∕4HANA-Systems
in einem Werkzeug für den Planungsprozess bearbeitet werden, das seine Daten in der Datenbank speichert.
Um diese Anforderung noch individueller zu machen, soll es einige Administratoren geben, die die
Berechtigung haben, jederzeit Plandaten anzupassen, um falsche Eingaben zu korrigieren.
ABAP-Exit-Implementierung
Die typische ABAP-Exit-Implementierung dieser Beispiele ist direkt, indem die externen Daten mittels SQL-
Befehlen der ABAP-Laufzeit aus der Datenbank gelesen und unter Berücksichtigung weiterer Informationen
wie Benutzername (sy-uname) Sätze in der korrespondierenden Struktur geprüft, abgeleitet oder erzeugt
werden.
Implementierung auf der SAP HANA-Datenbank
Sie können die Planung durch die Verwendung datenbankinterner Routinen in der SAP HANA-Datenbank SAP
HANA-optimiert ausführen. In diesem Fall empfehlen wir, die kundenspezifische Exit-Funktionalität für
Merkmalsbeziehungen und Datenscheiben ebenfalls direkt in der SAP HANA-Datenbank mittels SQLScript zu
implementieren. Andernfalls schöpfen Sie die Möglichkeiten der Performanceoptimierung nicht immer aus:
Plandaten müssten dann an die ABAP-Laufzeit übergeben und satzweise verarbeitet werden. Während das für
die Darstellung der Daten analytischer Queries keinen Nachteil darstellt, da die Daten in der ABAP-Laufzeit
ohnehin verfügbar sind, kann es sich auf die Performance nachteilig auswirken, wenn Disaggregation (Top-
Down-Verteilung) oder Planungsfunktionen auf Massendaten ausgeführt werden. In solchen Fällen findet
nämlich die ganze Datenverarbeitung in der SAP HANA-Datenbank statt; eine ABAP-Implementierung der Exit-
Funktionalität würde demnach verhindern, dass die Performance optimiert wird.
Planungskonzepte
 Hinweis
Beachten Sie folgendes: Auch wenn Sie für alle Methoden, die in Merkmalsbeziehungen und Datenscheiben
verwendet werden, SQLScript-Procedures implementieren, müssen dennoch auch die korrespondierenden
ABAP-Implementierungen vorhanden sein, weil das System in bestimmten Situationen die ABAP-
Äquivalente anstößt, um eine zusätzliche Datenübertragung zwischen dem SAP BW∕4HANA-System und
der SAP HANA-Datenbank zu vermeiden. Ziel ist es immer, die Algorithmen zu den Daten zu bringen. Die
Aufbereitung der Ergebnisliste für die Clients erfolgt in ABA; dafür sind auch Prüfungen auf der Grundlage
von Merkmalsbeziehungen und Datenscheiben relevant.
 Hinweis
Im Falle einer SQLScript-Implementierung werden die Namen der implementierenden SQLScript-

Procedures in der ABAP-Laufzeit bestimmt und weitere Parameter, die nur im AS ABAP verfügbar sind (wie
der Benutzername im Systemfeld sy-uname), für die spätere Verwendung in der SQLScript-
Implementierung ermittelt.
 Hinweis
Die drei Methoden CREATE, CHECK und ggf. DERIVE im ABAP-Fall und den SQL-Prozeduren, die in der SAP
HANA von IF_RSPLS_CR_EXIT_HDB~ GET_SQLSCRIPT_INFO in den Parametern
E_PROCEDURE_NAME_CREATE, E_PROCEDURE_NAME_CHECK und E_PROCEDURE_NAME_DERIVE
ermittelt werden, müssen immer konsistente Ergebnisse liefern. Das bedeutet: Es müssen genau
diejenigen Sätze von CREATE erzeugt werden, die von CHECK als gültig erkannt werden, und DERIVE muss
genau diejenigen Werte ergänzen, die von CHECK als gültig erkannt werden bzw. die von CREATE so
erzeugt würden.
Sofern Ihre Implementierungen (ABAP und SAP HANA) diese Voraussetzung nicht erfüllen, können die
Ergebnisse in ABAP und in der SAP HANA unterschiedliche Resultate liefern, auch wenn die Paare (CREATE
in ABAP und in der SAP HANA; CHECK in ABAP und in der SAP HANA und DERIVE in ABAP und in der SAP
HANA) identische Resultate berechnen.
Für die ABAP-Verarbeitung der Exits werden folgende Schnittstellen benötigt:
● IF_RSPLS_CR_EXIT : ABAP-Implementierung der Merkmalsbeziehungen

● IF_RSPLS_DS_EXIT : ABAP-Implementierung der Datenscheiben
Zusätzlich zu diesen Schnittstellen müssen für die Verarbeitung der Daten in der SAP HANA-Datenbank
weiterhin folgende Schnittstellen implementiert werden:
● IF_RSPLS_CR_EXIT_HDB : SQLScript-Implementierung der Merkmalsbeziehungen

● IF_RSPLS_DS_EXIT_HDB : SQLScript-Implementierung der Datenscheiben
Die SAP HANA-spezifischen Schnittstellen haben folgende Aufgaben:
1. Sie dienen als Markierungsschnittstellen, die anzeigen, dass die Verarbeitung der Daten - ohne Rücksicht
auf vorhandene Merkmalsbeziehungen und Datenscheiben vom Typ Exit - in der SAP HANA-Datenbank
ausgeführt werden soll.
2. Sofern sie die erforderlichen Informationen über die korrespondierenden SQLScript-Implementierungen
liefern, sollen diese Implementierungen aufgerufen werden, wenn die Datenverarbeitung in der SAP HANA-
Datenbank erfolgt und eine Datenübertragung an die ABAP-Laufzeitumgebung vermieden werden kann.
Planungskonzepte
SAP HANA-spezifische Schnittstellen für Merkmalsbeziehungen und Datenscheiben [Seite 19]

Parameter für die SQLScript-Procedures [Seite 20]
Transport und Lifecycle Management der erforderlichen Objekte [Seite 22]
1.2.4.1 SAP HANA-spezifische Schnittstellen für

Merkmalsbeziehungen und Datenscheiben
Im folgenden wird ein Überblick über die Implementierung der SAP HANA-spezifischen Schnittstellen
IF_RSPLS_CR_EXIT_HDB (für Merkmalsbeziehungen) und IF_RSPLS_DS_EXIT_HDB (für Datenscheiben)
gegeben. Sie enthalten zwei Methoden, GET_SQLSCRIPT_INFO und GET_SQLSCRIPT_ PARAMETERS.
Methode GET_SQLSCRIPT_INFO
Die Methode GET_SQLSCRIPT_INFO liefert die Namen der SQLScript-Procedures, die für die Exit-Verarbeitung
in der SAP HANA-Datenbank benötigt werden.
Die Methode GET_SQLSCRIPT_INFO der Schnittstelle IF_RSPLS_CR_EXIT_HDB hat folgende

Exportparameter:
Exportparameter der Methode GET_SQLSCRIPT_INFO des IF_RSPLS_CR_EXIT_HDB

Parameter Beschreibung
E_DB_SCHEMA_NAME Name eines Datenbank-Schemas, das die auszuführenden

SQLScript-Procedures enthält.
Wenn der Parameter von der Methode nicht gesetzt wird,

wird das DB-Schema des SAP-Systems übernommen.
E_PROCEDURE_NAME_CHECK Name der SQLScript-Procedure, die die Implementierung

der Methode zum Prüfen von Merkmalsbeziehungen enthält.
E_PROCEDURE_NAME_DERIVE Name der SQLScript-Procedure, die die Implementierung

der Methode zum Ableiten von Merkmalsbeziehungen ent
hält.
E_PROCEDURE_NAME_CREATE Name der SQLScript-Procedure, die die Implementierung

der Methode zum Anlegen von Merkmalsbeziehungen ent
hält.
E_PARAMETER_NAME Name einer DDIC-Struktur, die zusätzliche Parameter be

schreibt, die zur Laufzeit an die SQLScript-Procedures über
geben werden.

werden keine zusätzlichen Informationen vom Anwendungs
server übermittelt.
Planungskonzepte
Die Methode GET_SQLSCRIPT_INFO der Schnittstelle IF_RSPLS_DS_EXIT_HDB hat folgende
Exportparameter:
Exportparameter der Methode GET_SQLSCRIPT_INFO des IF_RSPLS_DS_EXIT_HDB

E_DB_SCHEMA_NAME Name eines Datenbank-Schemas, das die auszuführenden

SQLScript-Pprocedures enthält.

wird das DB-Schema des SAP-Systems übernommen.
E_PROCEDURE_NAME_PROTECTED Name der SQLScript-Procedure, die die Implementierung

der Prüfung des Datenschutzes in Datenscheiben enthält.
E_PARAMETER_NAME Name einer DDIC-Struktur, die zusätzliche Parameter be

schreibt, die zur Laufzeit an die SQLScript-Procedures über
geben werden.

werden keine zusätzlichen Informationen vom Anwendungs
server übermittelt.
 Hinweis
Wenn die Methode GET_SQLSCRIPT_INFO einen der Parameter mit Procedure-Namen nicht setzt, wird als
Fallback-Lösung die korrespondierende ABAP-Implementierung zur Laufzeit gerufen.
Methode GET_SQLSCRIPT_ PARAMETERS
Wenn der Exportparameter E_PARAMETER_NAME der Methode GET_SQLSCRIPT_INFO den Namen der DDIC-
Struktur zurückgegeben hat, wird die Methode GET_SQLSCRIPT_ PARAMETERS aufgerufen. Diese Methode
hat sowohl bei Merkmalsbeziehungen als auch bei Datenscheiben den folgenden Exportparameter:
Exportparameter der Methode GET_SQLSCRIPT_PARAMETERS

E_S_PARAMETER Struktur, um zusätzliche Parameter an die SQLScript-Proce

dures zu übergeben.
Zur Laufzeit hat dieser Parameter den Typ der DDIC-Struk

tur mit dem Namen E_PARAMETER_NAME.
1.2.4.2 Parameter für die SQLScript-Procedures

Die SQLScript-Procedures für die Implementierung der Methoden zum Prüfen und Ableiten von
Merkmalsbeziehungen bzw. zum Schützen von Datenscheiben benötigen jeweils einen IN- und einen OUT-
Tabellen-Parameter, der die Struktur der modellierten Merkmalsbeziehung bzw. Datenscheibe aufweist. Die IN-
Parameter-Tabelle enthält alle Datensätze, die in der Implementierung verarbeitet werden sollen. Die OUT-
Parameter-Tabelle gibt die verarbeiteten Datensätze zurück.
Planungskonzepte
Methoden für Merkmalsbeziehungen
● CHECK
○ IN: Alle Datensätze, die von der Procedure verarbeitet werden sollen.
○ OUT: Diejenige Teilmenge der Datensätze der IN-Parameter-Tabelle, die in Hinsicht auf die
Merkmalsbeziehung als gültig betrachtet wird.
● DERIVE
Merkmalsbeziehung mit Ableitung der Zielmerkmalswerte aus den Quellmerkmalen als gültig
betrachtet wird.
● CREATE
○ OUT: Für die CREATE-Procedure gibt es nur einen OUT-Tabellen-Parameter mit der Struktur der
modellierten Merkmalsbeziehung. Wir empfehlen, wichtige Teile der Selektion über die Parameter-
Struktur zu übergeben.
Methoden für Datenscheiben
● PROTECTED
Datenscheibe als gegen Änderungen geschützt betrachtet wird.
Für alle Methoden gilt:
Wenn eine DDIC-Struktur von der Methode GET_SQLSCRIPT_INFO im Parameter E_PARAMETER_NAME

zurückgegeben wurde, muss die SQLScript-Procedure zusätzliche skalare Parameter haben, deren Namen den
Komponentennamen der DDIC-Struktur entsprechen.
 Empfehlung
Wir empfehlen, das Programm RSPLS_SQL_SCRIPT_TOOL zu verwenden: Sie gelangen auf das Bild SAP
BW∕4HANA-Planung: Tool für SQLScript-Exits. Auf der dritten Registerkarte Beispiel-Merkmalsbeziehung/
Datenscheibe können Sie sich auf der Grundlage Ihrer eigenen Objekte Beispiel-Coding für
Merkmalskombinationen und Datenscheiben erzeugen. Der Merkmalskombinationsschritt bzw. die
Datenscheibe muss dafür schon vom Type Exit angelegt sein. Beachten Sie, dass das System
Merkmalskombinationen und Datenscheiben aus Performancegründen manchmal auch dann im ABAP
ausführt, wenn eine SQLScript-Implementierung vorliegt. Deswegen müssen Sie vom Ergebnis identische
Implementierungen für SAP HANA und ABAP erstellen.
Planungskonzepte
Fallback bei SAP HANA-optimierter Prozessierung
Wenn Sie die SAP HANA-optimierte Prozessierung benötigten, können in Verbindung mit ABAP-Exit-
Implementierungen in Merkmalsbeziehungen und Datenscheiben Probleme auftreten.
Um dies zu vermeiden, können Sie auch in SAP HANA Implementierungen für die benötigten Funktionen
bereitstellen und SQLScript für die Implementierung verwenden. Dies setzt jedoch die Arbeit mit einer
zusätzlichen Entwicklungsumgebung und Programmiersprache voraus.
Eine einfacherere, allerdings in Hinsicht auf die Performance nicht mit dieser aufwändigen Lösung zu
vergleichende Möglichkeit wird in dem folgenden Hinweis beschrieben: 1956085 .
1.2.4.3 Transport und Lifecycle Management der

erforderlichen Objekte
Die ABAP-Klassen, die die SQLScript-Metadaten-Regeln implementieren, können mit dem CTS (Change and
Transport System) des ABAP Application Servers transportiert werden. Welche Möglichkeiten es für die
korrespondierenden SQLScript-Procedures in Hinsicht auf die Softwarelogistik gibt, wird im folgenden
erläutert.
Erzeugen der SQLScript-Procedures pro System
Sie können die Procedures für jedes System Ihrer Systemlandschaft über die SQL-Konsole des SAP HANA-
Studios oder über die Transaktion DBACOCKPIT des SAP BW∕4HANA-Systems als SAP HANA-Katalog-Objekte
erzeugen. Dieser Weg wird seitens der Software nur durch das Syntaxhighlighting im SAP HANA-Studio
begleitet, ist aber auch sehr einfach und direkt. Zu beachten ist allerdings, dass jede Änderung an der
Implementierung einer Procedure in allen Systemen Ihrer Systemlandschaft manuell nachgezogen werden
muss.
Erzeugen der SQLScript-Procedures als SAP-HANA-Repository-Objekte
Sie können die Procedure als ein SAP HANA-Repository-Objekt im Entwicklungssystem anlegen und aktivieren.
(Das aktivierte Objekt liegt dann im DB-Schema _SYS_BIC.) Auf diese Weise können Sie die Funktionen der
SAP HANA-Softwarelogistik einsetzen, um nachgelagerte Systeme zu versorgen. Dieser Weg erfordert einigen
Konfigurationsaufwand, um eine arbeitsfähige Entwicklungsumgebung im SAP HANA-Studio aufzusetzen, wird
sich aber in vielen Fällen lohnen, da Sie eine besseren Systemunterstützung erhalten und das Lifecycle
Management für SQLScript-Procedure-Implementierungen in SAP HANA nutzen können.
Planungskonzepte
Erzeugen der SQLScript-Procedures als AMDPs
Wir empfehlen, die SQLScript-Procedures als AMDPs (ABAP Managed Database Procedures) zu
implementieren, um diese Implementierung in das Transportwesen des AS ABAP zu integrieren. Damit steht
Ihnen für die SQLScript-Procedures dasselbe Transport- und Lifecycle-Management zur Verfügung, wie Sie es
von ABAP-Entwicklungsobjekten kennen.
 Hinweis
Weitere Informationen über AMDP finden Sie in der ABAP - Schlüsselwortdokumentation im Internet unter
● http://help.sap.com/abapdocu_740/en/index.htm?file=abenamdp.htm
● http://help.sap.com/abapdocu_740/de/index.htm?file=abenamdp.htm
1.3 Aggregationsebene
Verwendung
Aggregationsebenen werden als InfoProvider für die Planung verwendet: Mit einer Aggregationsebene
modellieren Sie die Ebene, auf der Daten manuell über eingabebereite Queries oder automatisch über
Planungsfunktionen verändert werden dürfen.
Eine Aggregationsebene wird durch eine Menge von Merkmalen und Kennzahlen des zugrunde liegenden
InfoProviders festgelegt. Die in der Aggregationsebene enthaltenen Kennzahlen werden über die nicht in der
Aggregationsebene enthaltenen Merkmale verdichtet.
Im einfachsten Fall liegt eine Aggregationsebene auf einem für die Planung geeignete Basis-InfoProvider.
Aggregationsebenen können zusätzlich auch auf InfoProvidern angelegt werden, die für die Planung geeignet
sind, weil sie einen für die Planung geeigneten Basis-InfoProvider enthalten. Sie können mehrere
Aggregationsebenen zu einem InfoProvider anlegen.
Einfache Aggregationsebene
Einer einfachen Aggregationsebene liegt ein Basis-InfoProvider zugrunde.
Komplexe Aggregationsebene
Einer komplexen Aggregationsebene liegt ein InfoProvider zugrunde, der mindestens einen für die Planung
geeignete Basis-InfoProvider, aber keine einfache Aggregationsebene enthält.
 Beispiel
Sie möchten mit einer Planungsfunktion vom Typ Kopieren aktuelle Daten von einem Ist-Basis-InfoProvider
in einen Plan-Basis-InfoProvider kopieren. Dafür verwenden Sie eine Aggregationsebene auf der Grundlage
eines InfoProviders, der den Plan- und den Ist-InfoProvider enthält.
Aggregationsebenen können nicht geschachtelt aufgebaut werden.
Planungskonzepte
Bei einer komplexen Aggregationsebene ist zu beachten, wie Datensätze aus dem Basis-InfoProvider in den
diesen enthaltenden InfoProvider (und damit auch in die Aggregationsebene) eingebettet werden und wie das
System Änderungen an Datensätzen der Aggregationsebene in den Basis-InfoProvider zurückschreibt.
Bedingungen, die für beide Typen von Aggregationsebenen gelten
● Mindestens eine Kennzahl muss in der Aggregationsebene enthalten sein.

● Die verwendeten Kennzahlen müssen die Datenbankaggregationen SUM, MIN, MAX oder NO2 haben. Bei
MIN oder MAX können Kennzahlwerte nur angezeigt, aber nicht durch die manuelle Planung oder
Planungsfunktionen verändert werden.
● Für Kennzahlen vom Typ Datum oder Zeit wird nur der Datentyp DEC unterstützt.
● Referenzierende Kennzahlen (und damit auch Bestandskennzahlen oder auch die
Binnenumsatzeliminierung) werden in Aggregationsebenen nicht unterstützt.
● Wenn ein Merkmal geklammert ist und in einer Aggregationsebene verwendet wird, muss die
Aggregationsebene alle klammernden "Eltern"-Merkmale ebenfalls enthalten.
● Wenn eine Kennzahl in einer Aggregationsebene verwendet wird und keine feste Maßeinheit oder Währung
hat, muss die Aggregationsebene das entsprechende Merkmal für die Einheit enthalten.
● Wenn eine Kennzahl mit Ausnahmeaggregation in einer Aggregationsebene verwendet wird, muss die
Aggregationsebene auch das Merkmal für die Ausnahmeaggregation enthalten, sofern dieses selbst im
zugrunde liegenden InfoProvider vorkommt.
● Die Aggregationsebene erbt ein Navigationsattribut von dem zugrunde liegenden InfoProvider, wenn sie
das Basismerkmal des Navigationsattributs enthält.
● Eine komplexe Aggregationsebene kann nicht angelegt werden, wenn ein Merkmal eines Basis-
InfoProviders zwei verschiedene Merkmale im darüberliegenden InfoProvider versorgt.
● Wenn ein Merkmal an demjenigen InfoProvider konstant ist, der als Grundlage für eine Aggregationsebene
dient, muss dieses Merkmal in die Aggregationsebene aufgenommen werden.
● Eine Aggregationsebene, die ein Direct Update DataStore-Objekt oder ein beplanbares InfoObject
unmittelbar oder mittelbar über einen InfoProvider verwendet, muss so viele Merkmale enthalten, dass der
Schlüssel des DataStore-Objektes bzw. des InfoObjects gefüllt werden kann. Wenn nicht alle
Schlüsselfelder direkt in der Aggregationsebene aufgenommen werden, sind Merkmalsbeziehungen
erforderlich, die die fehlenden Schlüsselfelder aus den in der Aggregationsebene aufgenommenen
Merkmalen ableiten können.
 Hinweis
Unter Umständen kann das System diese Bedingung in der Modellierung der Aggregationsebene nicht
vollständig prüfen, da es die Ableitungsschritte erst zur Laufzeit ermittelt. Daher kann es vorkommen,
dass das System eine in diesem Sinne unvollständige Modellierung erst zur Laufzeit prüft und Daten
aufgrund dieser unvollständigen Modellierung über Planungsfunktionen nicht verändern kann bzw. die
Eingabebereitschaft von Zellen in Queries zurücknimmt.
● In den folgenden Fällen kann ein CompositeProvider nicht als Basis für eine Aggregationsebene verwendet
werden (siehe 2091885 ):
○ Der CompositeProvider enthält einen JOIN mit einem planbaren Basis-InfoProvider.
○ Der CompositeProvider enthält ein Merkmal A, das aus einem anderen enthaltenen InfoProvider einem
weiteren Merkmal B zugeordnet ist; dabei referenziert weder A das Merkmal B not B das Merkmal A.
○ Der CompositeProvider enthält ein Navigationsattribut, das aus einem planbaren Basis-InfoProvider
nicht versorgt wird.
○ Der CompositeProvider enthält einen planbaren Basis-InfoProvider mit dem Filter Criteria.
Bedingungen, die für eine Aggregationsebene gelten, die Merkmale als Kennzahlen verwendet
Planungskonzepte
Wenn Sie ein Merkmal A aus dem Datenteil eines Direct Update DataStore-Objekt oder eines beplanbaren
InfoObjects als Kennzahl 1KYF_A und als Merkmal A in die Aggregationsebene aufnehmen, so können Sie das
Merkmal A in einer Query nicht als freies Merkmal in Queries aufnehmen; Sie können es nur im Filter oder in
eingeschränkten Kennzahlen verwenden. Planungsfunktionen können solche Aggregationsebenen nicht
verwenden.
● DataStore-Objekt als Basis-InfoProvider

Nur in einem Direct Update DataStore-Objekt können Merkmale aus dem Datenteil als Kennzahlen
exponiert werden.
 Beispiel
Ist A ein Merkmal, so bezeichnet 1KYF_A die zugehörige Kennzahl.
Beachten Sie, dass sich Einheitenmerkmale immer im Schlüssel des planbaren DataStore-Objektes
befinden sollten. Einheitenmerkmale können somit auch nicht als Kennzahlen exponiert werden.
Für geklammerte Merkmale im Datenteil eines DataStore-Objektes gelten die folgenden Regeln, wenn
diese als Kennzahlen in einer Aggregationsebenen aufgenommen werden sollen.
○ Wenn Merkmal C an Merkmal A geklammert ist und 1KYF_C in die Aggregationsebene aufgenommen
werden soll, muss A entweder im Schlüssel des DataStore-Objekts liegen und A muss in die
Aggregationsebene aufgenommen werden, oder A muss im Datenteil des DataStore-Objekts liegen
und dann als 1KYF_A in die Aggregationsebene aufgenommen werden.
○ Wenn Merkmal C an Merkmal B geklammert ist und 1KYF_B in die Aggregationsebene aufgenommen
werden soll, muss auch 1KYF_C in die Aggregationsebene aufgenommen werden.
● InfoObject (Merkmal) als Basis-InfoProvider
In einer Aggregationsebene, die für die Stammdatenplanung verwendet werden soll, können nur solche
Merkmale über eine eingabebereite Query geändert werden, die Attribute und bzw. oder Texte besitzen.
Wenn ein solches InfoObject mit den Modellierungseigenschaften Usable as InfoProvider und Planning
Mode ausgezeichnet ist und im Planungsmodus läuft, werden dessen Attribute und bzw. oder Texte als
Kennzahlen exponiert.
 Beispiel
Ist B ein Attribut des InfoObjects, so bezeichnet 1KYF_B die zugehörige Kennzahl. Wenn ein Objekt
zeitabhängige Attribute und bzw. oder Texte hat, wird ein zusätzliches Paar von Kennzahlen für das
Zeitfälligkeitsintervall von Attributen und bzw. oder Texten generiert (z.B. 1KYF_1TXTDATEFROM und
1KYF_1TXTDATETO).
Beachten Sie, dass man auf Stammdaten nicht mit Planungsfunktionen planen kann.

Einfache Aggregationsebene [Seite 26]
Komplexe Aggregationsebene [Seite 27]
Stammdatenplanung [Seite 156]
Dieser Link führt in die Dokumentation der Aufgabe, wie man eine Aggregationsebene bearbeitet.
Planungskonzepte
Dieser Link führt in die Dokumentation einer Analysefunktion, die eine Aggregationsebene als InfoProvider und
eine eingabebereite Query zur Bearbeitung von Kurztexten in einer Query benötigt.
1.3.1 Einfache Aggregationsebene
Verwendung
Das folgende Beispiel zeigt, wie das System arbeitet, wenn ein Kennzahlwert (manuell oder automatisch)
verändert wird.
Gegeben sei ein für die Planung geeigneter Basis-InfoProvider mit den Merkmalen Produkt, Produktgruppe,
Version und Jahr sowie der Kennzahl Umsatz. Die Aggregationsebene ALVL enthält dieselben Objekte mit
Ausnahme des Merkmals Produkt.
Produkt Produktgruppe Version Jahr Umsatz
P1 PG1 V1 2017 10
P2 PG1 V1 2017 20
P3 PG2 V1 2017 42
Die Kennzahl Umsatz enthält die Datenbankaggregation SUM. Dementsprechend erhalten wir, wenn die
Bewegungsdaten zur Aggregationsebene ALVL ohne jede Einschränkung von der Datenbank gelesen werden,
das folgende Ergebnis:
Produktgruppe Version Jahr Umsatz
PG1 V1 2017 30
PG2 V1 2017 42
Wenn der Kennzahlwert Umsatz von 30 auf 40 geändert und als neuer Wert gesichert wird, schreibt das
System einen neuen Satz mit der Differenz des Kennzahlwertes in den Basis-InfoProvider:
# PG1 V1 2017 10
In solchen Delta-Sätzen erhalten alle Merkmale des Basis-InfoProviders, die in der Aggregationsebene nicht
enthalten sind, den initialen Wert (nicht zugeordnet: #). (Hierbei gehen wir davon aus, dass keine Ableitungen
verwendet wurden; weitere Informationen über dieses Konzept finden Sie unter Merkmalsbeziehungen [Seite
9]).
Planungskonzepte
1.3.2 Komplexe Aggregationsebene
Verwendung
Die folgenden Beispiele zeigen:
● wie das System Datensätze aus den Basis-InfoProvidern in den diese enthaltenden InfoProvider einbettet
● wie das System neue oder veränderte Datensätze des InfoProviders in die in diesem enthaltenen Basis-
InfoProvidern zurückschreibt
Beispiel: Merkmal Produkt im InfoProvider IP
Gegeben sei ein InfoProvider IP, der den Ist-Basis-InfoProvider BIP_I und den Plan-Basis-InfoProvider BIP_P
enthält. Der Ist-Basis-InfoProvider BIP_I enthält die Merkmale Produkt, Produktgruppe, Version und Jahr sowie
der Kennzahl Gewinn. Der Plan-Basis-InfoProvider BIP_P enthält dieselben Objekte mit Ausnahme des
Merkmals Produkt. Auf dem InfoProvider IP wird eine Aggregationsebene ALVL_IP definiert, die alle Merkmale
des InfoProviders enthält.
Die folgenden zwei Datensätze der Basis-InfoProvider ergeben die folgenden Datensätze im InfoProvider IP:
Datensatz in Ist-Basis-InfoProvider BIP_I
Produkt Produktgruppe Version Jahr Gewinn
P1 PG1 V1 2017 10
Datensatz in Plan-Basis-InfoProvider BIP_P
Produktgruppe Version Jahr Gewinn
PG1 V1 2017 30
Datensätze im InfoProvider IP (oder ALVL_IP)
InfoProvider Produkt Produktgruppe Version Jahr Gewinn
BIP_I P1 PG1 V1 2017 10
BIP_P # PG1 V1 2017 30
Die Datensätze im InfoProvider IP werden - technisch gesprochen - über eine UNION-Operation aus den Sätzen
der zugrunde liegenden InfoProvider erzeugt. Der InfoProvider ist stets enthalten, so dass auf der Ebene eines
Datensatzes die "Herkunft" des jeweiligen Datensatzes bekannt ist.
Wenn in der manuellen Planung oder über Planungsfunktionen neue Datensätze erzeugt werden, stellt das
System sicher, dass jeder Satz des InfoProviders eindeutig ohne Informationsverlust den im InfoProvider
enthaltenen InfoProvidern wieder zugeordnet werden kann.
Die folgende Tabelle zeigt ein Beispiel für einen Datensatz, dessen Zuordnung nicht möglich wäre.
Beispiel eines Satzes im InfoProvider IP, dessen Zuordnung nicht möglich wäre
Planungskonzepte
InfoProvider Produkt Produktgruppe Version Jahr Gewinn
BIP_P P1 PG1 V1 2017 43
Der Datensatz gehört zum InfoProvider BIP_P. Allerdings liefert dieser InfoProvider im CompositeProvider kein
Produkt. Daher ist hier P1 nicht zulässig.
In der manuellen Planung sind Datenzellen, die zu solchen Sätzen führen würden, nicht eingabebereit. In
Planungsfunktionen prüft das System, dass solche Datensätze nicht gesichert werden können.
 Hinweis
Eine analoge Situation kann für Kennzahlen in komplexen Aggregationsebenen auftreten. Wenn K eine
Kennzahl im InfoProvider IP ist, die aus dem Ist-Basis-InfoProvider BIP_I, jedoch nicht aus dem Plan-Basis-
InfoProvider BIP_P versorgt wird, so ist diese Kennzahl in einem Datensatz im InfoProvider IP mit dem Plan-
Basis-InfoProvider BIP_P immer initial. Dieser Wert kann auch nicht verändert werden.
1.4 Filter
Ein Filter ist ein Objekt, das den mehrdimensionalen Ausschnitt von Daten aus einem Datenbestand
beschreibt.
Verwendung
Filter werden in Reporting, Analyse und Planung beispielsweise dafür verwendet, Daten auf einen bestimmten
Geschäftsbereich, bestimmte Produktgruppen oder bestimmte Zeiträume einzuschränken. Durch diese
Segmentierung des Datenbestandes kann erreicht werden, dass Anwender oder Anwendergruppen nur Zugriff
auf die für sie relevanten Daten erhalten, oder dass innerhalb eines Anwendungsszenarios nur bestimmte
Datenbereiche sichtbar sind.
Innerhalb der Planung in SAP Business Planning and Consolidation, version for SAP BW/4HANA, (Embedded-
Konfiguration) legen Filter die Selektion für die Daten fest, auf der eine Planungsfunktion operiert. Eine
Planungssequenz besteht aus einer Menge von Planungsfunktionen mit jeweils einem den Funktionen
zugeordneten Filter.
 Beispiel
Sie möchten Ihre Bewegungsdaten in Ihrem InfoProvider um den Faktor 10% umwerten. Sie möchten
allerdings, dass sich die Umwertung nur auf bestimmte Kundengruppen bezieht. Hierzu legen Sie einen
Filter an, der die gewünschten Kundengruppen enthält, die Sie tatsächlich umwerten möchten.
Filter können in Planungsfunktionen und in Queries wiederverwendet werden.
Planungskonzepte
Integration
Sie können mehrere Filter zu einem InfoProvider in den BW-Modellierungswerkzeugen anlegen.
Voraussetzungen
Um einen Filter für die Verwendung in der Planung anzulegen, benötigen Sie eine Aggregationsebene.
Funktionsumfang
Die Filterdefinition enthält diejenigen Merkmale einer Aggregationsebene, die Sie einschränken möchten. Ein
Filter hat die folgenden Bestandteile:
Bestandteil Beschreibung
Merkmalseinschränkungen Auf dem Einschränkungsdialog können Sie über Einzelwerte,

Wertebereiche, Hierarchieknoten und Variablen das Merk
mal weiter einschränken. Diese Merkmalseinschränkungen
bestimmen die Selektion der Daten eines Filters.
Vorschlagswerte Vorschlagswerte sind nur in Queries relevant. Sie können

analog zu Merkmalseinschränkungen definiert werden und
legen den initialen Filterzustand der Query zur Ausführung
fest.
Für die Bestimmung von zeitabhängigen Selektionen, z.B. für die Ermittlung einer zeitabhängigen Hierarchie zu
zeitabhängigen Hierarchieknotenselektionen, kann ein Filter-Stichtag angegeben werden.
 Hinweis
Für die Synchronisierung von Stichtagen in Queries, Filtern, Merkmalsbeziehungen, Datenscheiben und
Planungsfunktionen kann die ausgelieferte Variable 0PLANDAT auf dem Merkmal 0CALDAY verwendet
werden. Damit können Sie sicherstellen, dass in diesen Objekten derselbe Stichtag verwendet wird.
Der Funktionsumfang eines Filters richtet sich nach seinem jeweiligen Einsatz entweder in einer
Planungsfunktion oder in einer Query:
Filter in Planungsfunktionen
Im Zusammenhang mit Planungsfunktionen beschreibt ein Filter in den Merkmalseinschränkungen diejenigen

Daten, die für die Ausführung einer Planungsfunktion verwendet werden.
Selektionen in den Vorschlagswerten werden nicht für die Ausführung der Planungsfunktion herangezogen.
Zusätzlich kann ein Stichtag des Filters zur Ermittlung von zeitabhängigen Selektionen verwendet werden.
Filter in einer Query
Planungskonzepte
Die in den Merkmalseinschränkungen einer Query definierten Werte schränken die Datenmenge ein, die für das
weitere Filtern zur Laufzeit einer Query zur Verfügung steht. Ein Filtern auf einem Merkmalswert außerhalb
dieser Wertemenge ist dann nicht mehr möglich.
Die Vorschlagswerte bestimmen hierbei den initialen Filterzustand der Query.
Die Einstellungen Änderbar bei Ausführung und Nur Einzelwert beziehen sich grundsätzlich stets auf die
Verwendung von Filtern im Zusammenhang einer Query:
Änderbar bei Ausführun g legt fest, ob die in den Merkmalseinschränkungen getroffene Werteauswahl bei der
Ausführung der Query geändert werden kann. Diese Einstellung ist Vorraussetzung für die Definition von
Vorschlagswerten zu einem Merkmal.
Wenn die Option Änderbar bei Ausführung gewählt wurde, kann mit der Option Nur Einzelwert festgelegt
werden, ob nur ein Einzelwert für das Filtern der Query verwendet werden darf.
1.5 Variable
Verwendung
Variablen dienen der Parametrisierung einer Query, eines Filters, einer Merkmalsbeziehung oder Datenscheibe
oder einer Planungsfunktion. Beim Ausführen einer Query oder Planungsfunktion werden sie mit Werten
gefüllt.
Abhängig davon, für welche Objekte Sie Variablen definieren möchten, gibt es verschiedene Variablentypen:
Variablen stellen Platzhalter für Merkmalswerte, Hierarchien, Hierarchieknoten, Texte und Formelelemente dar.
Die Verarbeitungsart bestimmt, wie eine Variable zur Laufzeit einer Query oder Planungsfunktion mit einem
Wert gefüllt wird.
 Beispiel
Durch die Verwendung von Variablen kann z.B. eine Planungsfunktionsdefinition als Grundlage für viele
unterschiedliche Planungsfunktionen dienen: Sie möchten eine Planungsfunktion vom Typ Kopieren
anlegen, die Ihre aktuellen Daten von der aktuellen Version in eine beliebige Version kopiert. Sie setzen für
das Merkmal Version in den Nach-Parametern der Planungsfunktion eine Variable ein. Vor dem Ausführen
der Planungsfunktion entscheiden Sie, in welche Version die aktuellen Daten kopiert werden.
 Hinweis
Für Formelvariablen, die in Planungsfunktionen z.B. für die Umwertungsfunktion verwendet werden, steht
die Verarbeitungsart Ersetzungspfad nicht zur Verfügung. Zudem wird hierbei nur die Dimension Zahl
unterstützt.
Textvariablen können Sie in eingabebereiten Queries uneingeschränkt verwenden.
Planungskonzepte
Gültigkeitsbereich von Variablen
Variablen sind wiederverwendbare Objekte, d.h. sie sind nicht abhängig von einem InfoProvider, sondern nur
vom jeweiligen InfoObject. Eine Variable, die für ein InfoObject definiert wurde, steht in allen InfoProvidern zur
Verfügung, die dieses InfoObject verwenden.
Die gleiche Variable kann an unterschiedlichen Orten unterschiedliche Werte haben. Wann immer eine Variable
mit einem Wert gefüllt wird, wird eine eigene Instanz der Variable erzeugt. In gewissen Fällen werden
verschiedene Instanzen (und damit die Werte) von Variablen zu einer einzigen verschmolzen, das heißt die
Variable hat in allen beteiligten Objekten den gleichen Wert. Dies geschieht z.B. bei Verwendung von einer
Variable in zwei verschiedenen Queries. Dies stellt allerdings die Ausnahme dar.
Funktionsumfang
Variablen dienen zur flexibleren Einstellung bzw. Parametrisierung von Objekten. Folgende Objekte
unterstützen die Verwendung von Variablen:
Objekt Verwendung von Variablen
Queries (insbesondere eingabebereite Queries) ● für die Parametrisierung von Merkmalseinschränkun

gen in der Query
● in Formeln, Bedingungen, Exceptions
● als Platzhalter für Texte
Beim Starten einer Query können Variablen durch einen vor

eingestellten Wert oder durch eine Benutzereingabe Werte
zugewiesen werden.
Filter zur Parametrisierung von Merkmalseinschränkungen, die

den Filter beschreiben
Planungsfunktionen für die Parametrisierung von Bedingungen und Parametern

z.B. für die Parametrisierung des Umwertungsfaktors in der
Planungsfunktion des Typs Umwertung
Variablen können durch einen voreingestellten Wert oder

durch einen Befehl in der Anwendung Werte zugewiesen
werden:
Merkmalsbeziehungen zur Parametrisierung der verwendeten Hierarchie
Datenscheiben zur Parametrisierung von Merkmalseinschränkungen, die

die Datenscheibe beschreiben
Variablen, die in Merkmalsbeziehungen und in Datenscheiben verwendet werden, müssen zum

Ausführungszeitpunkt einen voreingestellten Wert besitzen.
Zeitpunkte von Variablenaufrufen
Planungskonzepte
Die Einsatzmöglichkeiten von Variablen führen zu jeweils unterschiedlichen Zeitpunkten, an denen Variablen
neu durchlaufen werden und dadurch gegebenenfalls neue Werte annehmen.
Einsatzmöglichkeit Zeitpunkt des Variablenaufrufs
Query 1. Die Variable wird bei jedem Neustart der Anwendung

prozessiert.
2. Beim Aufruf des Dialogfensters Werte für Variablen
ändern. Dies erzwingt einen Neustart der Query.
Das Beenden des Variablenbildes mit OK ändert den
Wert der Variable nicht, wenn Sie keinerlei aktive Ände
rung vorgenommen haben. Dies führt bei eingabeberei
ten Variablen des Typs Exit dazu, dass der Exit nicht
durchlaufen wird, um den Vorschlagswert im Dialog
fenster neu zu bestimmen (da dieser den bereits ge
setzten Wert überschreiben könnte). Variablen im Be
reich der Vorschlagswerte bzw. Variablen zur Bestim
mung der Präsentationshierarchie übernehmen den
Wert des aktuellen Filterzustands des Merkmals bzw.
die aktuell eingestellte Präsentationshierarchie.
Explizit gesetzte Variablenwerte haben Vorrang vor im
plizit gesetzten Variablenwerten.
Planungsfunktion bei der Ausführung derPlanungsfunktion
Explizit gesetzte Variablenwerte haben Vorrang vor implizit

gesetzten Variablenwerten. Daraus ergeben sich die fol
gende Priorisierungsbedingungen beim Füllen einer Variable:
1. Wird die Variable ausdrücklich im Befehl gesetzt?

2. Gibt es ein voreingestellter Wert?
Planungssequenz siehe Planungsfunktion
Filter in Planungssequenz bei jeder Ausführung der Planungssequenz
Datenscheibe beim Erstaufruf
Es ist nicht möglich, durch eine Änderung von Variablen Da

tenscheiben zu ändern.
 Hinweis
In Datenscheiben verwendete Variablen müssen immer
automatisch ersetzbar sein.
Merkmalsbeziehung siehe Datenscheibe
Verschmelzung von Variablen
Wenn sich zwei gleichnamige Variablen in zwei verschiedenen Objekten befinden, dann erzeugt das System
Instanzen dieser Variablen, d.h. fortan existieren physisch zwei Variablen. In gewissen Konstellationen führt das
Planungskonzepte
System eine automatische Verschmelzung dieser Instanzen durch, so dass alle Variableninstanzen denselben
Wert erhalten.
Konstellation Verschmelzung
Gleichnamige Variablen in zwei Queries ja
Gleichnamige Variablen in Planungsfunktion und Query abhängig vom Client
Gleichnamige Variablen in Planungssequenz und Query siehe Planungsfunktion
Filter und Planungsfunktion innerhalb einer Planungsse ja

quenz
Datenscheibe oder Merkmalsbeziehung mit beliebigem an nein

deren Objekt
1.6 Planungsfunktionen
Planungsfunktionen dienen zur systemgestützten Bearbeitung bzw. Erzeugung von Daten.
Verwendung
Eine Planungsfunktion beschreibt, auf welche Weise die Bewegungsdaten einer bestimmten
Aggregationsebene verändert werden. Hierfür werden festgelegt:
● der Name der Aggregationsebene

● der Planungsfunktionstyp
● die Art der Verwendung von Merkmalen
● die Parameterwerte
Der Planungsfunktionstyp gibt das Verfahren vor, nach dem die Daten von einer Planungsfunktion verändert
werden. SAP bietet Ihnen folgende Standard-Planungsfunktionstypen [Seite 41]:
● Einheitenumrechnung
● Erzeugen Kombinationen
● Formel
● Kennzahlwerte setzen
● Kopieren
● Löschen
● Löschen ungültige Kombinationen
● Prognose
● Umbuchen
● Umbuchen nach Merkmalsbeziehungen
Planungskonzepte
● Umwertung
● Verteilen nach Referenzdaten
● Verteilen nach Schlüsseln
● Währungsumrechnung
Sie können auch kundeneigene Planungsfunktionstypen implementieren.
Voraussetzungen
Im System sind folgende Objekte vorhanden:
● Aggregationsebenen, auf welchen Planungsfunktionen angelegt werden. Planungsfunktionen können auf

jeder aktiven Aggregationsebene angelegt und ausgeführt werden.
 Hinweis
Wenn eine Funktion, die sich auf Daten eines DataStoreObjekts bezieht, auf einer Aggregationsebene
läuft, die InfoProvider enthält, die mit Deltas fortgeschrieben werden (wie ein DataMart DataStore-
Objekt), werden die Kennzahlen nur auf Null gesetzt. Dies betrifft die folgenden
Planungsfunktionstypen:
○ DSO-Sätze löschen
○ Physisches Löschen ungültiger Daten im DSO
○ DSO-Daten umbuchen und Quelldaten physisch löschen
○ DSO-Daten auf der Basis von Merkmalsbeziehungen umbuchen
Beachten Sie, dass Sie auf Aggregationsebenen, die als Kennzahlen verwendete Merkmale enthalten,
nicht alle Typen von Planungsfunktionen anlegen können. Unterstützt sind folgende
Planungsfunktionstypen:
○ DSO-Sätze löschen
○ Erzeugen Kombinationen
○ Kopieren
○ Kopieren (ohne Berücksichtigung von Nullsätzen)
○ Löschen
○ Umbuchen
○ DSO-Daten umbuchen und Quelldaten physisch löschen
● Filter, die zum Zeitpunkt der Ausführung den Planungsfunktionen mitgegeben werden. Ein Filter bestimmt,
auf welchen Daten die Planungsfunktion ausgeführt wird. Die Planungsfunktion sperrt die über den Filter
definierten Daten in denjenigen planungsrelevanten InfoProvidern, die an der Aggregationsebene
teilhaben. Der Filter muss auf derselben Aggregationsebene definiert sein wie die Planungsfunktion.
Funktionsumfang
Für eine Planungsfunktion muss der Typ der Planungsfunktion und die Aggregationsebene definiert sein, auf
der die Planungsfunktion arbeiten soll. Weiterhin können die Merkmalsverwendung, die Bedingungen und die
Planungskonzepte
zugehörigen Parametersätze verändert werden. Es kann festgelegt werden, wie die veränderten Daten
verarbeitet werden.
Der Funktionsumfang soll im folgenden am Beispiel des Anlegens einer Planungsfunktion vom Typ Umbuchen
erläutert werden.
Die folgende Tabelle zeigt die Daten des InfoProviders vor dem Ausführen der Planungsfunktion:
Vor dem Ausführen der Planungsfunktion
P1 PG1 V1 2017 10
P2 PG1 V1 2017 20
Alle Sätze der Version V1 sollen auf V2 umgebucht werden. Dies können Sie erreichen, indem Sie sämtliche
Kennzahlen umbuchen. Die folgende Tabelle zeigt die Situation nach dem Ausführen der Planungsfunktion:
Nach dem Ausführen der Planungsfunktion
P1 PG1 V1 2017 0
P2 PG1 V1 2017 0
P1 PG1 V2 2017 10
P2 PG1 V2 2017 20
Nach dem Umbuchen bleiben unter V1 Nullsätze zurück; unter V2 entstehen die gewünschten Sätze.
Merkmalsverwendung
Der Planungsfunktionstyp definiert, welche Optionen bei den Merkmalsverwendungen zur Verfügung stehen
und welche Parameter die Planungsfunktion hat. Die Menge der Parameter eines Planungsfunktionstyps stellt
einen Parametersatz dar.
Über die Merkmalsverwendung werden die Merkmale der Aggregationsebene in zu verändernde Merkmale
und Blockmerkmale (d.h. Merkmale, die nicht verwendet werden) eingeteilt. Damit wird festgelegt, welche
Merkmalswerte die Planungsfunktion bei der Verarbeitung eines Datensatzes verändert. Blockmerkmale
bleiben konstant.
 Beispiel
Wenn Sie eine Planungsfunktion vom Typ Umbuchen für den oben beschriebenen Fall anlegen, prüfen Sie
zunächst, von welchen Merkmalswerten Sie auf welche umbuchen möchten, und kennzeichnen dann das
entsprechende Merkmal für wird verändert. Da Sie die Daten von der Version V1 auf die Version V2
umbuchen möchten, setzen Sie das Kennzeichen für das Merkmal Version als wird verändert (in diesem
Falle gleichbedeutend mit wird umgebucht).
Außerdem können Sie über die Merkmalsverwendung Blockmerkmale als Bedingungsmerkmale auswählen.
Parametersätze und Bedingungen
Planungskonzepte
Sie können nun die Parametersätze verändern. Bei den meisten Planungsfunktionen werden sämtliche
Bewegungsdaten mit dem gleichen Parametersatz verarbeitet. In diesem Fall wurde kein Blockmerkmal als
Bedingungsmerkmal ausgewählt, und es muss lediglich ein Parametersatz eingegeben werden.
 Beispiel
Der Parametersatz des Planungsfunktionstyps Umbuchen enthält eine Tabelle zur Auswahl der
Kennzahlen, die umgebucht werden sollen, und eine Tabelle, in der Sie Von-Nach-Wertepaare auf den
umzubuchenden Merkmalen eintragen können. In der Kennzahlauswahl setzen Sie das Kennzeichen für
Alle Kennzahlen auswählen. In der Tabelle Von- und Nach-Werte für den Umbuchungsvorgang legen Sie über
Zeile anlegen einen Eintrag an, der unter Von den Wert V1 und unter Nach den Wert V2 enthält. Hiermit ist
die Planungsfunktion zum Umbuchen fertig.
Wenn Sie unterschiedliche Sätze aus den Bewegungsdaten mit unterschiedlichen Parametersätzen ausführen
möchten, müssen Sie mit Bedingungen arbeiten. Hierfür müssen Sie über die Merkmalsverwendung
mindestens ein Blockmerkmal als Bedingungsmerkmal auswählen.
 Beispiel
Wenn es möglich sein soll, z.B. die geplante Produktion für Produkte der Produktgruppe PG1 um 5% zu
erhöhen, die Produkte der Produktgruppe PG2 jedoch um 10%, wählen Sie hierfür die Produktgruppe als
Bedingungsmerkmal.
Bei den Parametern können Sie dann mehrere Bedingungs-Parametersatz-Paare anlegen. Als Bedingung
geben Sie für jedes Paar eine Merkmalseinschränkung Filter auf die Bedingungsmerkmale an. Zu jedem Paar
können Sie dann den zugehörigen Parametersatz verändern.
 Hinweis
Technisch gesehen wird die Methode, die die Planungsfunktion tatsächlich ausführt, mehr als einmal
aufgerufen. Dazu werden die zu verarbeitenden Daten, die durch den Filter ausgewählt wurden, in Blöcke
aufgeteilt. Jede in den Daten vorkommende Kombination von Merkmalswerten bezüglich der
Blockmerkmale bildet einen eigenen Block (daher auch der Name Blockmerkmale). Bei
Planungsfunktionstypen, die mit Referenzdaten arbeiten, können weitere Blöcke hinzukommen (z.B. Typ
Kopieren). Die eigentliche Methode wird dann für jeden Block einmal mit einer Tabelle von Sätzen
aufgerufen. Dabei enthält die Tabelle diejenigen Sätze der Daten, die genau der Merkmalskombination des
Blockes auf den Blockmerkmalen entsprechen.
Für jeden Block prüft das System, ob es ein Bedingungs-Parametersatz-Paar gibt, so dass der Block der
Bedingung entspricht. Dabei wird der Block gegen die Bedingungen entlang der Reihenfolge der
Bedingungs-Parametersatz-Paare getestet. Das erste Paar, bei dem der Block der Bedingung entspricht,
wird verwendet, d.h. die Methode des Planungsfunktionstyps wird mit dem Block und dem zur Bedingung
passenden Parametersatz ausgeführt. Die weiteren Paare werden dann nicht berücksichtigt. Die Methode
wird also für jeden Block höchstens einmal ausgeführt.
Variablen in Planungsfunktionen
Es stehen in vielen Planungsfunktionstypen die im SAP BW∕4HANA-System üblichen Variablentypen zur

Verfügung (siehe Variable [Seite 30]).
Umgang mit Nullsätzen
Fast alle Planungsfunktionstypen lesen keine Nullsätze und schreiben auch keine Null-Deltasätze in den Puffer.
Ausnahmen sind Kopieren und Erzeugen Kombinationen: Beide lesen Nullsätze und schreiben Null-Deltasätze.
Planungskonzepte
Der Funktionstyp Formel mit Verarbeitung von Nullsätzen (0RSPL_FORMULA_ZERO) verarbeitet auch Sätze, bei
denen alle Kennzahlen gleich Null sind (Nullsätze).
Veränderte Daten verarbeiten
Beim Typ der Planungsfunktion können Sie einstellen, ob die Planungsfunktion die Daten in Blöcken oder
immer alle Daten auf einmal verarbeitet. Eine Planungsfunktion, die Datenblöcke verarbeitet, kann so
parametrisiert werden, dass sie nur diejenigen Blöcke (oder eine geringe Obermenge) verarbeitet, in denen
Daten liegen, die der Benutzer in der gleichen Sitzung vorher geändert hat. Solche Planungsfunktionen
verarbeiten nur ganz wenige Daten. Damit wird die Laufzeit stark verkürzt.
Dabei kann der Benutzer Daten geändert haben, die im Filter liegen, oder Daten, die als Referenzdaten dienen.
 Beispiel
Ein Beispiel ist die Kopierfunktion, die Daten aus der Version V1 nach V2 kopiert. Die Datenblöcke werden in
diesem Beispiel so gebildet, dass alle Daten zu Blöcken zusammengefasst werden, die in allen Merkmalen
außer dem Versionsmerkmal den gleichen Merkmalswert haben. Die Referenzdaten kommen aus der
Version V1. Die zu ändernden Daten liegen in der Version V2. Die Funktion verarbeitet nur die Blöcke, in
denen Daten aus Version V1 oder Version V2 geändert wurden.
Bei einer Planungsfunktion bestimmt der Filter, welche Daten geändert werden dürfen. Aus den Parametern
geht hervor, welche Referenzdaten dazu benötigt werden. Jetzt werden zusätzlich die geänderten Daten
gelesen. Für jeden geänderten Datensatz innerhalb des Filters und innerhalb der Referenzdaten werden die
Merkmalswerte der Blockmerkmale aufgesammelt und ersetzen die ursprüngliche Selektion. Durch dieses
Verfahren kann es dazu kommen, dass mehr Datenblöcke als nötig verarbeitet werden. Dies sollte aber das
Ergebnis der Planungsfunktion nicht verändern.
Verarbeitet werden die Änderungen an Daten seit dem letzten Sichern.
Welche Daten geändert wurden, wird im Regelfall auf der Aggregationsebene der Planungsfunktion bestimmt.
Es ist auch möglich, eine andere Aggregationsebene anzugeben, z.B. die Aggregationsebene der Query, mit der
die Daten geändert wurden.
 Hinweis
Das Verhalten kann auch für eine Planungssequenz eingestellt werden.
 Empfehlung
Wir empfehlen die Festlegung, nur die Blöcke mit veränderten Daten zu verarbeiten, in folgendem Szenario
anzuwenden:
Zu Beginn der Sitzung findet der Benutzer seine Daten in einem konsistenten Zustand vor. (Dies wurde vom
Administrator sichergestellt.) Im Laufe der Sitzung ändert der Benutzer einige Daten. Der Benutzer führt
jetzt Planungsfunktionen aus, die prüfen, ob die Daten konsistent sind, oder es werden Berechnungen
durchgeführt, die die Daten in einen konsistenten Zustand überführen. Geeignet sind Planungsfunktionen,
bei denen sich ab der zweiten Ausführung die Daten nicht mehr ändern. Der Filter sollte so eingeschränkt
werden, dass er die Daten umfasst, die der Benutzer während der Sitzung bearbeiten darf. Prinzipiell soll
die Planungsfunktion alle Daten verarbeiten können. Durch die Art, wie die Selektion gebildet wird,
verarbeitet das System stets eine möglichst kleine Menge an Blöcken. Es kann allerdings sein, dass bei sich
ergebenden Schnittmengen eine etwas größere als die minimale Menge verarbeitet wird.
Planungskonzepte
Der Filter der Planungsfunktion sollte keine Variablen enthalten, die im Laufe der Sitzung geändert werden.
Ansonsten verarbeitet das System ggf. nur die geänderten Daten mit der letzten Variablenbelegung im
Filter und es besteht die Gefahr, dass nicht alle geänderten Daten erfasst werden.
Es bietet sich an, eine solche Planungsfunktion auf die Drucktaste Sichern zu legen, da die Änderungen nur
bis zum letzten Sichern gemerkt werden.
Ablauf einer Planungsfunktion: Verteilung nach Schlüsseln [Seite 38]

Standard-Planungsfunktionstypen [Seite 41]
Planungsfunktion anlegen [Seite 187]
Planungsfunktionstyp implementieren [Seite 109]
1.6.1 Ablauf einer Planungsfunktion: Verteilung nach

Schlüsseln
Daten eines InfoProviders werden beispielhaft mit Hilfe einer Planungsfunktion vom Typ Verteilung nach
Schlüsseln verändert. Schritt für Schritt wird gezeigt, wie das System beim Ablauf der Planungsfunktion
arbeitet.
Verwendung
Für das Jahr "2017" und die Version "V1" sollen die geplanten Mengen pro Produkt neu auf die zur Verfügung
stehenden Werke "W1" und "W2" verteilt werden. Dabei bleibt die Gesamtmenge pro Produkt erhalten. Sie soll
jedoch gleichmäßig auf die Werke verteilt werden.
Die folgende Tabelle zeigt die Daten des InfoProviders vor dem Ausführen der Planungsfunktion:
Jahr Version Produkt Werk Menge
2017 V1 P1 W1 10
2017 V1 P1 W2 20
2017 V1 P2 W1 60
2017 V1 P2 W2 40
Planungskonzepte
Die folgende Tabelle zeigt das Ergebnis der Ausführung der Planungsfunktion:
2017 V1 P1 W1 15
2017 V1 P1 W2 15
2017 V1 P2 W1 50
2017 V1 P2 W2 50
Tatsächlich schreibt die Planungsfunktion allerdings nur Deltasätze in den InfoProvider. Die folgende Tabelle
zeigt die tatsächlich geschriebenen Deltasätze:
2017 V1 P1 W1 5
2017 V1 P1 W2 -5
2017 V1 P2 W1 -10
2017 V1 P2 W2 10
Anlegen der Planungsfunktion
Wenn die Planungsfunktion angelegt wird, muss zunächst festgelegt werden, innerhalb welcher Merkmale sich
die Werte verändern. Bezüglich der Merkmale Jahr, Version und Produkt soll die Summe der Werte nicht
verändert werden; daher bleiben diese Merkmale konstant und werden Blockmerkmale. Die Verteilung der
Kennzahlwerte soll bezüglich der Merkmalswerte erfolgen; daher muss das Merkmal Werk in der
Merkmalsverwendung als zu verändernd ausgewählt werden.
Die Parameter der Verteilungsfunktion (siehe Verteilung nach Schlüsseln [Seite 95]) werden wie folgt
eingestellt.
● Über die Tabelle zur Kennzahlauswahl wird festlegt, dass als einzige Kennzahl die Kennzahl Menge verteilt
werden soll.
● Da innerhalb eines Blockes (Merkmalskombination {Jahr, Version, Produkt}) immer die Gesamtsumme neu
verteilt werden soll, wird die Verteilungsart Top-Down-Verteilung mit der Einstellung Alles verteilen
angewendet.
● Als Nach-Werte werden die Werke "W1" und "W2" eintragen und erhalten jeweils einen identischen
Schlüssel (z.B. 1).
Ablauf der Planungsfunktion
Die Planungsfunktion soll mit einem Filter, der das Jahr auf "2017" und die Version auf "V1" einschränkt,
ausgeführt werden. Die Planungsfunktion führt die folgenden Schritte aus.
1. Das System lädt zunächst den Filter und die Planungsfunktion.

2. Es ersetzt die enthaltenen Variablen.
3. Es prüft den Filter und die Planungsfunktion auf Konsistenz.
Planungskonzepte
4. Über den Filter fordert das System die ausgewählten Daten an und lädt sie in den Puffer. In diesem Beispiel
wird angenommen, dass durch den Filter die oben in der Tabelle "Vor dem Ausführen der
Planungsfunktion" dargestellten Sätze ausgewählt und der Planungsfunktion übergeben werden. Ob das
System dabei die vorhandenen Nullsätze liest oder nicht berücksichtigt, hängt vom jeweiligen Typ der
Planungsfunktion ab. Bei den Verteilungsfunktionen liest das System keine Nullsätze.
5. Das System teilt an Hand der Merkmalsverwendung die Bewegungsdaten in Blöcke ein. Dies
veranschaulichen die Tabellen im Anschluss an die Darstellung des Ablaufs. Es entstehen zwei Blöcke, die
durch die hier abgebildeten Merkmalskombinationen definiert sind.
Block Nr. Jahr Version Produkt
1 2017 V1 P1
2 2017 V1 P2
6. Pro Block sucht das System über die Merkmalskombination des Blockes den richtigen Parametersatz aus
den Bedingungs-Parametersatz-Paaren. Da in diesem Beispiel keine Bedingungen angelegt worden sind,
werden beide Blöcke mit dem einzigen vorhandenen Parametersatz ausgeführt.
7. Pro Block führt das System das eigentliche Verfahren aus, in diesem Falle also die Verteilung. Die Tabellen
im Anschluss an die Darstellung des Ablaufs zeigen die pro Block entstehenden Vorher-Nachher-Werte
sowie die entstehenden Deltasätze.
8. Abhängig vom jeweiligen Typ der Planungsfunktion verarbeitet das System die ggf. entstehenden Nullsätze
oder berücksichtigt sie nicht. In diesem Beispiel gibt es keine Nullsätze.
9. Das System prüft,
○ ob die entstandenen Sätze bezüglich der Stammdaten und Merkmalsbedingungen konsistent sind,
○ ob sie nicht durch Datenscheiben geschützt sind,
○ ob sie innerhalb des übergebenen Filters liegen.
Mit Rücksicht auf die Performance prüft das System nicht alle Merkmalsbeziehungen, sondern nur
diejenigen, die zu verändernde Merkmale betreffen. Dies ist möglich, da angenommen werden kann, dass
Sätze, die von der Datenbank gelesen werden, den Merkmalsbeziehungen genügen, und Fehler somit nur in
Verbindung mit zu verändernden Feldern entstehen können. Fehlerhafte Sätze sollten gelöscht oder auf
gültige Kombinationen umgebucht werden. Dazu können Sie die Planungsfunktionstypen Löschen
ungültige Kombinationen oder Umbuchen nach Merkmalsbeziehungen verwenden.
 Hinweis
Wenn eine Planungsfunktion mit Nullsätzen arbeitet (z.B. beim Planungsfunktionstyp Kopieren), prüft
das System alle möglichen Merkmalsbeziehungen, da es sich um einen stornierten Satz handeln kann.
10. Wenn das System alle Blöcke erfolgreich verarbeitet hat, schreibt es die gesammelten Deltasätze in den
Puffer zurück. Gegebenenfalls findet im Puffer eine Ableitung statt (siehe Merkmalsbeziehungen [Seite 9]
und Aggregationsebene [Seite 23]).
 Hinweis
Wenn auch nur bei einem einzigen erzeugten Satz eine Konsistenzprüfung fehl schlägt, schreibt die
gesamte Planungsfunktion nichts in den Puffer zurück.
Übersicht Block 1
Planungskonzepte
2017 V1 P1 W1 10
2017 V1 P1 W2 20
2017 V1 P1 W1 15
2017 V1 P1 W2 15
2017 V1 P1 W1 5
2017 V1 P1 W2 -5
Übersicht Block 2
2017 V1 P2 W1 60
2017 V1 P2 W2 40
2017 V1 P2 W1 50
2017 V1 P2 W2 50
2017 V1 P2 W1 -10
2017 V1 P2 W2 10
1.6.2 Standard-Planungsfunktionstypen
Die Standard-Planungsfunktionstypen sind Bestandteil des Systems. Indem Sie einen Standard-
Planungsfunktionstyp auf einer bestimmten Aggregationsebene anwenden, definieren Sie eine
Planungsfunktion diesen Typs.
Planungskonzepte
Verwendung
SAP liefert die folgenden Standard-Planungsfunktionstypen aus.
● Datei hochladen [Seite 42]

● Einheitenumrechnung [Seite 43]
● Erzeugen Kombinationen [Seite 44]
● Formel [Seite 44]
● Formel mit Verarbeitung von Nullsätzen [Seite 72]
● Kennzahlwerte setzen [Seite 72]
● Kopieren [Seite 73]
○ Kopieren (ohne Berücksichtigung von Nullsätzen) [Seite 74]
● Löschen [Seite 74]
○ DSO-Sätze löschen [Seite 75]
● Löschen ungültige Kombinationen [Seite 75]
○ Physisches Löschen ungültiger Daten im DSO [Seite 76]
● Prognose [Seite 76]
● Protokoll einer Prozesskette ausgeben [Seite 90]
● Prozesskette starten [Seite 90]
● Prozesskette starten [Seite 90]
● Umbuchen [Seite 91]
○ DSO-Daten umbuchen und Quelldaten physisch löschen [Seite 91]
● Umbuchen nach Merkmalsbeziehungen [Seite 92]
○ DSO-Daten auf der Basis von Merkmalsbeziehungen umbuchen [Seite 93]
● Umwertung [Seite 93]
● Verteilung nach Referenzdaten [Seite 94]
● Verteilung nach Schlüsseln [Seite 95]
● Währungsumrechnung [Seite 96]
1.6.2.1 Datei hochladen
Mit Planungsfunktionen vom Typ Hochladen von Dateien aus AO (File Upload from AO,
0RSPL_FILE_UPLOAD_AO) können Sie lokale CSV-Dateien von Ihrem lokalen Gerät in Ihre SAP Analysis for
Office-Anwendung ab Version 2.7 hochladen. Sobald eine Planungsfunkion dieses Typs ausgeführt wird,
erscheint ein Dialogfenster, auf dem Sie eine Datei auswählen können. Diese wird dann an das Backend
transferiert und weiter verarbeitet.
Wenn Sie die Planungsfunktion bearbeiten, müssen Sie zuerst Dateieinstellungen festlegen, die das Format
der Daten in der CSV-Datei beschreiben. Im Einzelnen sind dies: Trennzeichen (CSV), Feldbegrenzerzeichen,
Datumsformat und Dezimalnotation.
Weitere Einstellungen betreffen den Überschreibemodus und das Vorhandensein von doppelten Sätzen in der
Datei:
● Beim Überschreibemodus können Sie festlegen, ob vorhandene Daten vollständig überschrieben (O =

OVERWRITE), nur aktualisiert (U = UPDATE) oder hinzugefügt (C = COLLECT) werden.
Planungskonzepte
● Beim Prüfen auf doppelte Sätze können Sie festlegen, dass deren Vorhandensein eine Fehlermeldung
erzeugt (X) oder dass die Kennzahlen der Sätze addiert werden (# oder Leerzeichen).
Desweiteren ist es erforderlich anzugeben, in welcher Zeile die Daten in der CSV-Datei beginnen.
Vor der ersten Zeile mit Daten können Mapping-Informationen stehen. Als Mapping-Information steht in einer
Spalte der Name eines InfoObjects. Im Bildbereich InfoObjects Dateispalten zuordnen (Map InfoObjects to File
Columns)) können Sie angeben, in welcher Zeile die Mapping-Information steht. Hier kann eine Tabelle mit der
Zuordnung von Spaltennummer in der Datei und Name des InfoObjects bearbeitet werden.
Im Bildbereich Filterwerte aus Datei (Filter values from file)) können Sie die Daten so synchronisieren, dass man
genau diejenigen Werte im Filter hat, die auch in der Datei sind. Damit sperrt und überschreibt man nur solche
Daten, die in der Datei sind. Für Merkmale, die hier ausgewählt sind, werden die Einzelwerte aus der Datei
gelesen und in den Filter aufgenommen. Die Menge aller Einzelwerte ist systemseitig auf 100 begrenzt, damit
nicht zu viele Sperren gesetzt werden.
Es gibt ein BADI BADI_RSPLFA_FILE_UPLOAD, in dem Sie die CSV-Datei programmatisch anpassen können.
Sie können eine Planungsfunktion vom Typ Hochladen von Dateien aus AO auch in eine Planungssequenz
einbinden.
1.6.2.2 Einheitenumrechnung
Verwendung
Mit dem Funktionstyp Einheitenumrechnung können Sie Einheiten aus Kennzahlen in andere Kennzahlen über
Einheitenrelationen umrechnen.
In der Tabelle Quell-/Zielkennzahl-Umrechnungsart können Sie mehrere Umrechnungen angeben. Für jede
Umrechnung müssen Sie eine Einheiten- bzw. Mengenumrechnungsart auswählen. Der Wert in der
Zielkennzahl wird überschrieben. Dies gilt auch dann, wenn die Quellkennzahl leer ist. Der Wert der
Quellkennzahl bleibt bei der Einheitenumrechnung erhalten. Dadurch kann die Funktion mehrmals
hintereinander ausgeführt werden, ohne dass sich die Ergebnisse verändern. Damit dies auch gewährleistet ist,
wenn die Quellkennzahl und die Zielkennzahl identisch sind und die Quelleinheit aus dem Datensatz verwendet
wird, gibt es hierfür eine spezielle Logik: Falls es bereits einen Wert in der Zieleinheit gibt, wird dieser dann
vernachlässigt, wenn Werte in der Quelleinheit vorhanden sind, die nicht die Zieleinheit besitzen. Andernfalls
wird der Wert in der Zieleinheit übernommen.
Zu verändernde Merkmale können bei dieser Funktion nur die Einheitenfelder sein.
Planungskonzepte
1.6.2.3 Erzeugen Kombinationen
Verwendung
Mit dem Funktionstyp Erzeugen Kombinationen können Sie zu einer Aggregationsebene Nullsätze zu allen
erlaubten Kombinationen gemäß den Stammdaten und Merkmalskombinationen erzeugen lassen. Dies sind
genau diejenigen Kombinationen, die auch bei der Prüfung auf dieser Aggregationsebene gültig sind.
Dieser Funktionstyp erlaubt keine weitere Einstellungen: Da stets für die gesamte Aggregationsebene neue
Datensätze erzeugt werden, müssen sämtliche Merkmale zu verändernd sein. Der Funktionstyp arbeitet also
ohne Blockmerkmale.
Der Funktionstyp schreibt (wie beim Kopieren) Nullsätze.
Kopieren [Seite 73]
1.6.2.4 Formel
Der Planungsfunktionstyp Formel bietet Ihnen eine einfache Programmiersprache zur Manipulation von
Bewegungsdaten.
Wie in vielen Makrosprachen für Geschäftsanwendungen sind folgende Bestandteile verfügbar:
● Variablenkonzept inkl. DATA-Anweisung für Datendeklarationen und Hilfsvariablen

● Ausdrücke
● Operationen und Funktionen
● Bedingte Anweisungen
● Schleifenkonstrukte
● Meldungsausgabe
● Aufruf von Funktionsbausteinen
● Interne Tabellen
● Unterroutinen
● INCLUDE von Formeln
● Zugriff auf InfoProvider
● Kommentarfunktion
Sie können Zeilenkommentare verwenden, Anfangsmarkierung (zu Zeilenbeginn) ist '*'.
 Hinweis
Wenn Sie die SAP HANA-optimierte Prozessierung des SAP Business Planning and Consolidation, version
for SAP BW/4HANA, (Embedded-Konfiguration) einsetzen, erreichen Sie insbesondere bei
Planungskonzepte
Planungsfunktionen vom Typ Formel eine deutliche Performancesteigerung, siehe SAP-Hinweis 1637199
.
Interne Datenobjekte [Seite 45]

Referenzdaten [Seite 46]
Formel oder eigener Planungsfunktionstyp? [Seite 49]
Datendeklaration [Seite 50]
Ausdrücke [Seite 51]
Operatoren und Funktionen [Seite 52]
Bedingte Anweisungen [Seite 58]
Schleifenkonstrukte [Seite 59]
Meldungsausgabe [Seite 61]
Aufruf von Funktionsbausteinen [Seite 62]
Interne Tabellen [Seite 63]
Unterroutinen [Seite 63]
INCLUDE von Formeln [Seite 64]
Zugriff auf InfoProvider [Seite 65]
Beispiele für Formelanwendungen [Seite 66]
1.6.2.4.1 Interne Datenobjekte
Eine Formel wird in der Regel nicht nur einmal sondern mehrmals ausgeführt, nämlich exakt je einmal für jedes
interne Datenobjekt.
Wenn Sie eine Planungsfunktion ausführen, wählen Sie zunächst einen Filter aus. Der Filter beschreibt eine
Menge von Bewegungsdaten. Diese Menge von Bewegungsdaten wird in kleinere Datenobjekte aufgeteilt. Wenn
eine Formel Referenzdaten benötigt, werden diese Datenobjekte zusätzlich aus diesen Referenzdaten gebildet.
 Achtung
Wenn keine Datenobjekte gebildet werden können, wird eine Formel nicht ausgeführt.
Die Datenobjekte unterscheiden sich nur in den Merkmalswerten der zu verändernden Merkmale. Die Werte
der anderen Merkmale sind gleich. Falls keine zu verändernden Merkmale ausgewählt sind, wird die Formel für
jeden Bewegungsdatensatz einmal ausgeführt. Jeder Kennzahlwert im Datenobjekt kann dann eindeutig über
die Angabe der Merkmalswerte der zu verändernden Merkmale und die Angabe des Kennzahlnamens
adressiert und durch Funktionen verändert werden.
 Hinweis
Für ein besseres Verständnis der Arbeitsweise einer Formel können Sie eine Query definieren, in der alle zu
verändernden Merkmale in die Schlüsselspalten, die restlichen Merkmale in den Kopf gestellt werden. Die
Planungskonzepte
Formel wird dann für alle Kombinationen abgearbeitet. Sie müssen die Query eventuell um Spalten mit
Referenzdaten erweitern.
 Empfehlung
Wir empfehlen, die Werte im Filter bezüglich der in der Formel nicht zu verändernden Merkmale möglichst
stark einzuschränken, damit wenige Datenobjekte gebildet werden.
 Hinweis
Für Planungsfunktionen vom Typ Formel gibt es ein Debugging-Script

(RSPLFC_DEBUGGING_SCRIPT_FOX), mit dem Formeln analysiert werden können.
1.6.2.4.2 Referenzdaten
Zugriff auf Referenzdaten
Sie haben zwei Möglichkeiten, um auf Referenzdaten zuzugreifen:
1. Sie nehmen das Feld, aufgrund dessen sich die Referenzdaten von den Daten des aktiven Planungsfilters
unterscheiden, als zu veränderndes Feld auf, z.B. Version ( 0VERSION). Die Operanden schreiben sie dann
wie folgt:
{ ERLOES, 002 } = { ERLOES, 001 }.
Wenn in Version 002 noch keine Daten vorhanden sind, dann werden die internen Datenobjekte aus den
Daten aus Version 002 und zusätzlich aus Version 001 gebildet. Beim Ausführen der Formel werden Daten
in Version 002 erzeugt.
Diese Schreibweise eignet sich für Formeln, die aus Referenzdaten neue Daten erzeugen sollen.
2. Sie adressieren explizit Referenzdaten. Dazu geben Sie den Namen des Merkmals und den Wert im
Operanden an:
{ ERLOES } = { ERLOES | 0VERSION = 001 }.
Die Formel wird nur für Sätze in Version 002 durchlaufen, denn aus der Formel kann nicht ermittelt werden,
wie die Sätze aus Version 001 in Sätze aus Version 002 zu transformieren sind. Wenn keine Sätze
vorhanden sind, wird die Formel nicht durchlaufen. Es werden keine Sätze erzeugt.
Die Schreibweise eignet sich für Formeln, die Referenzdaten zur Bewertung von vorhandenen Daten
benötigen.
Planungskonzepte
 Beispiel
Im folgenden Beispiel sind die Daten der Version 002 im aktiven Planungsfilter. Die Formel wird für
jeden Datensatz des aktiven Filters durchlaufen. Da es keine zu verändernden Felder gibt, bestehen die
Datenobjekte aus einem Satz.
0VERSION 0COSTCENTER ERLOES
001 4711 3
001 0815 2
002 4711 9
Die folgende Tabelle zeigt das Ergebnis von: { ERLOES, 002 } = { ERLOES, 001 }.
001 4711 3
001 0815 2
002 4711 3
001 0815 2
Die folgende Tabelle zeigt die zwei Datenobjekte, die durch die Anwendung der Formel gebildet werden:
0COSTCENTER
4711
0815
Die folgende Tabelle zeigt das Ergebnis von: { ERLOES } = { ERLOES | 0VERSION = 001 }.
001 4711 3
001 0815 2
002 4711 3
Planungskonzepte
Die folgende Tabelle zeigt das Datenobjekt, das durch die Anwendung der Formel gebildet wird:
0VERSION 0COSTCENTER
002 4711
Vor der Ausführung der Parametergruppe wird aufgrund der Formel entschieden, welche
Referenzdaten benötigt werden. Für die Referenzdatenselektion wird die ursprüngliche Selektion
erweitert. Wenn z.B. im Planungsfilter nur Daten der Version 002 enthalten sind, wird aufgrund der
Formelzeile { ERLOES, 002 } = { ERLOES, 001 }. die Selektion um den Wert Version 001
erweitert.
Löschen der Selektion
Das System kann nicht immer vor dem Start einer Planungsfunktion vom Typ Formel entscheiden, welche
Referenzdaten benötigt werden. Wenn dies der Fall ist, löscht das System die Selektion. In den folgenden Fällen
kann dies eintreten:
● Benutzen der Funktion TMVL zur Veränderung des Wertes eines Zeitmerkmals
● Benutzen der Funktion ATRV oder ATRVT zum Lesen von Attributwerten
● Aufruf von Funktionsbausteinen.
Die Selektion wird nur dann gelöscht, wenn die Ergebnisse der Funktion zur Adressierung von Referenzdaten
verwendet werden. Hierzu folgt ein Beispiel:
 Beispielcode
DATA FISCPER TYPE 0FISCPER.

DATA ACTPER TYPE 0FISCPER.
ACTPER = VARV( AKTPERIO ).
FISCPER = ACTPER.
FISCPER = TMVL( FISCPER , -12 ).
{ ERLOES, ACTPER } = { ERLOES, FISCPER }.
Im Beispiel wird zuerst die Formelvariable ACTPER aus der globalen Variablen AKTPERIO gefüllt. In einem
zweiten Schritt wird dieser Wert der Variablen FISCPER zugewiesen. In einem dritten Schritt wird mittels der
Funktion TMVL der Wert von ACTPER um 12 vermindert. Abschließend wird der Wert der Kennzahl ERLOES in
der Periode FISCPER dem Wert der Kennzahl ERLOES in der Periode ACTPER zugewiesen.
Es gibt Fälle, in denen Sie die Selektion erhalten möchten, auch wenn aktuell die Referenzdaten nicht gelesen
werden können, z.B. weil man Daten lesen würde, für die man keine Berechtigung hat. Mit dem KEEP- und dem
ENHANCE-Statement können Sie die Selektion der Referenzdaten beeinflussen.
● Indem Sie das KEEP-Statement verwenden, können Sie vermeiden, dass das System die Selektion der
Referenzdaten löscht:
KEEP REFDATA SELECTION FOR 0FISCPER.
● Um explizit zusätzliche Referenzdaten anzufordern, können Sie das ENHANCE-Statement benutzen:
ENHANCE REFDATA SELECTION FOR 0FISCPER: 2015001, 2016001, #.
Sie können auch globale Variablen in einer solchen Liste verwenden:
ENHANCE REFDATA SELECTION FOR 0FISCPER: 2015001, VARIABLE FISCPERVAR.
Planungskonzepte
Um alle Daten, die es gibt, anzufordern, was dem Löschen des Filters entspricht, schreiben Sie:
ENHANCE REFDATA SELECTION FOR 0FISCPER: *.
Sowohl im KEEP- als auch im ENHANCE-Statement können Sie Navigationsattribute verwenden.

Navigationsattribute werden wie folgt notiert: Basismerkmalname, gefolgt von zwei Unterstrichten und dem
Namen des Attributes, also z.B.: 0MATERIAL__0GROUP.
Zugriff auf InfoProvider [Seite 65]
1.6.2.4.3 Formel oder eigener Planungsfunktionstyp?
Neben der Verwendung des Funktionstyps Formel haben Sie die Möglichkeit, eigene Planungsfunktionstypen
anzulegen, um Bewegungsdaten mit Hilfe einer Programmiersprache zu manipulieren. Wägen Sie die
folgenden Punkte gegeneinander ab, um eine Entscheidung für den einen oder anderen Funktionstyp zu
treffen.
● Planungsfunktionen vom Typ Formel erfordern nur geringen Einarbeitungsaufwand z.B. für einen
Endanwender im Controlling, der bereits eine algorithmische Programmiersprache oder eine
Makrosprache beherrscht und die meisten Problemstellungen mit der Formelsprache lösen kann.
● Eigene Planungsfunktionen müssen immer dann geschrieben werden, wenn Sie Funktionen benötigen, die
auf andere Weise nicht zur Verfügung stehen.
 Beispiel
Zur Kalkulation von Kosten muss auf kundeneigene Tabellen zugegriffen werden. Sie benötigen eine
spezielle Funktion, um in Formeln auf beliebige Tabellen zugreifen zu können.
● Es ist möglich, in Formeln Funktionsbausteine aufzurufen. Damit kann ein Teil der Logik in
Funktionsbausteinen und ein Teil der Logik in Formeln liegen.
● Generell kann jeder eigene Planungsfunktionstyp performanter implementiert werden als die
Formelrechnung. Grund dafür ist hauptsächlich, dass jeder Operand und jedes Ergebnis von etwas
komplexeren Formeln separat aus einer internen Tabelle gelesen wird. In einem selbst geschriebenen
Programm wird man diese Zugriffe natürlich optimieren. Dieser Performance-Gesichtspunkt ist bei
größeren Datenmengen ein wichtiges Entscheidungskriterium.
Formel [Seite 44]
Planungskonzepte
1.6.2.4.4 Datendeklaration
Eine Deklaration ist definiert als Festlegung von Aspekten einer Variable. Datendeklarationen werden mit dem
Wort DATA eingeleitet, gefolgt vom Namen der Hilfsvariablen.
Verwendung
Bei einer Datendeklaration muss der Name mit einem Buchstaben anfangen und kann dann Ziffern und
Buchstaben enthalten, jedoch keine Sonderzeichen.
Variablennamen müssen sich von Schlüsselworten wie DATA, ELSEIF oder SIN unterscheiden.
 Beispiel
DATA HELPVAR TYPE I.
DATA KEYRA TYPE KEYFIGURE_NAME.
 Achtung
Falls die Formelsyntax später um neue Schlüsselworte erweitert wird, werden eventuell vorhandene
gleichnamige Variablen ungültig.
 Empfehlung
Um Irrtümer zu vermeiden, empfehlen wir, dass Sie Variablen nicht wie Merkmalswerte benennen bzw.
Merkmalswerte in Hochkommata einschließen.
Folgende Variablentypen stehen zur Auswahl:
● I (Integerzahlen) für Indexoperationen

● F (Gleitkommazahlen) zum Rechnen
● D (Datum) für Datumsberechnungen
● STRING
● Variablen vom Typ der zu verändernden Merkmale.
Als Typbezeichnung dient hierbei der technische Name eines Merkmals. Falls Sie Kennzahlennamen über
Variablen setzen möchten, können Sie auch Variablen vom Typ KEYFIGURE_NAME definieren. Die gültigen
Datentypen können Sie sich über Datentypen anzeigen lassen.
Falls die Typbezeichnung Sonderzeichen (wie @, - oder &) enthält, muss der gesamte Name in einfache
Hochkommata gesetzt werden.
Außerdem können Sie Datentypen für Attribute anlegen. Falls die Attribute vom Typ Kennzahl sind, müssen
Sie dafür Hilfsvariablen vom Typ F oder I anlegen. Wenn Sie Attributwerte mit der Funktion ATRV lesen wollen,
benötigen Sie den technischen Namen des Attributs.
Des Weiteren können Sie beliebige InfoObjekte zur Datendefinition verwenden, selbst wenn dieses InfoObject
nicht zu der Aggregationsebene gehört.
Planungskonzepte
 Beispiel
DATA COSTCTR TYPE 0COSTCENTER
Dies ist möglich, obwohl 0COSTCENTER in diesem Beispiel keinen Bezug zur Aggregationsebene hat.
1.6.2.4.5 Ausdrücke
Im folgenden erhalten Sie einen Überblick darüber, welche Bestandteile Sie in Ausdrücken verwenden dürfen.
● Konstanten, die aus Ziffern und einem Dezimalpunkt bestehen.

● Variablen, die Sie mit der DATA-Anweisung deklariert haben.
● Operanden, die Sie über die Wertehilfe auswählen können.
○ Sobald in den Operanden Merkmalswerte auftauchen, sie also nicht über den Kennzahlnamen
adressiert werden, müssen die Operanden in geschweifte Klammern { und } eingeschlossen werden,
um eine Verwechslung von Operanden mit Konstanten zu vermeiden. Wenn kein Merkmal verändern
ist, können Sie als Operanden den Kennzahlnamen ohne Klammern anfügen. Die gültige Syntax und
insbesondere die richtige Reihenfolge der Merkmale zeigt das System oberhalb des Editors an. Über
die Wertehilfe können Sie sich auf einfache Weise gültige Operanden zusammenstellen.
○ Falls die Merkmalswerte in Operanden Leerzeichen oder Symbole wie +, -, * enthalten, müssen die
Merkmalswerte in Hochkommata eingeschlossen werden.
○ Für einen Merkmalswert gibt es jeweils eine externe und eine interne Darstellung. Datumswerte
werden z.B. extern als 3.12.1963 und intern als 19631203 dargestellt. Verwenden Sie in Formeln stets
die interne Darstellung. In Operanden können Sie anstelle von Merkmalswerten auch Variablen
verwenden.
○ Falls Kennzahlname das einzige zu verändernde Merkmal ist, und Sie eine Variable vom Typ
KEYFIGURE_NAME definiert haben, um damit Kennzahlen zu verändern, müssen Sie diese auch in
geschweiften Klammern einschließen. Die folgende Anweisung setzt alle Kennzahlen auf den Wert 1.
Das Konstrukt FOREACH füllt dabei die Variable KENNZ mit allen Kennzahlnamen der Kennzahlen, die in
der Ebene vorhanden sind:
 Beispielcode
DATA KENNZ TYPE KEYFIGURE_NAME.

FOREACH KENNZ.
{ KENNZ } = 1.
ENDFOR.
● Operatoren
● Funktionen mit keinem, einem oder mehreren Operanden
Datendeklaration [Seite 50]

Operatoren und Funktionen [Seite 52]
Planungskonzepte
1.6.2.4.6 Operatoren und Funktionen
Verwendung
Zur Berechnung von Kennzahlen stehen Ihnen eine Reihe Operatoren und mathematischer Funktionen zur
Verfügung.
Funktionen können mit keinem, einen oder mehreren Operanden arbeiten. Wenn keine speziellen Operanden
angegeben sind, können Sie neben den gültigen Operanden auch eine Konstante angeben.
Die Operanden Zinssatz und Prozentsatz werden in Prozent angegeben, also 10% als 10 und nicht als 0.1.
 Hinweis
Alle Funktionen liefern einen einfachen Ergebniswert zurück, keine Zeitreihe. Im Falle einer Abschreibung
wäre es allerdings wünschenswert, eine Zeitreihe mit den Abschreibungen zu erhalten. Um dies zu
erreichen, müssen Sie eine Formel für jeden Zeitpunkt füllen.
Mathematische Operatoren [Seite 52]

Vergleichsoperatoren [Seite 53]
Logische Operatoren [Seite 53]
Funktionen mit einem Operanden [Seite 54]
Funktionen mit zwei Operanden [Seite 55]
Funktionen mit drei Operanden [Seite 56]
Funktionen mit vier Operanden [Seite 57]
Funktion mit fünf Operanden [Seite 57]
Funktion ohne Operanden [Seite 57]
1.6.2.4.6.1 Mathematische Operatoren
Mathematischer Operator Bedeutung
+ bzw. - Verwendung als Vorzeichen (einstellige Operatoren)
+ Addition
- Subtraktion
* Multiplikation
Planungskonzepte
Mathematischer Operator Bedeutung
/ Division
DIV Ganzzahlige Division
MOD Modulo-Operation
** Potenzierung
1.6.2.4.6.2 Vergleichsoperatoren
Vergleichsoperator Bedeutung
> Größer
< Kleiner
>= Größer oder gleich
<= Kleiner oder gleich
= Gleich
<> Ungleich
Vergleichsoperatoren finden bei bedingten Anweisungen Anwendung.
Bedingte Anweisungen [Seite 58]
1.6.2.4.6.3 Logische Operatoren
Logischer Operator Bedeutung
AND Und
OR Oder
Planungskonzepte
Logischer Operator Bedeutung
NOT Nicht
1.6.2.4.6.4 Funktionen mit einem Operanden
Funktion Bedeutung
CEIL Kleinster ganzzahliger Wert, der nicht kleiner als x ist.
FLOOR Größter ganzzahliger Wert, der nicht größer als x ist.
TRUNC Ganzzahliger Teil von x
FRAC Dezimalteil von x
ABS Betrag (Absolutwert) |x| von x
SIGN Signum (Vorzeichen) von x
ACOS Arccos(x) im Bereich [-pi/2, pi/2], x aus [-1, 1]
ASIN Arcsin(x) im Bereich [0, pi], x aus [-1, 1]
ATAN Arctan(x) im Bereich [-pi/2, pi/2] (pi =

3.1415926535897932)
COS Cosinus eines Winkels, der im Bogenmaß angegeben wird.
SIN Sinus eines Winkels, der im Bogenmaß angegeben wird.
TAN Tangens eines Winkels, der im Bogenmaß angegeben wird.
COSH Hyperbelcosinus
SINH Hyperbelsinus
TANH Hyperbeltangens
EXP Exponentialfunktion zur Basis e = 2.7182818284590452
LOG Natürlicher Logarithmus (d.h. zur Basis e)
LOG10 Logarithmus von x zur Basis 10, x > 0.
SQRT Quadratwurzel einer nichtnegativen Zahl
STRLEN Länge einer Zeichenkette
Planungskonzepte
Funktion Bedeutung
VARV Variablenwert (Argument = Variablenname)
VARC Zahl der Werte einer Variablen (Argument = Variablenname )
DECIMALS Dezimalstellen (Argument = Kennzahlname)
CONVERT Kleinbuchstaben erzeugen alles mit vorangehendem ! wird

nach Kleinbuchstaben gewandelt
 Hinweis
Die Funktion CONVERT wandelt diejenigen Buchstaben ihres Argumentes in Kleinbuchstaben um, denen
ein ! - Zeichen vorgestellt ist. Enthält das Argument ein ! - Zeichen, muss ein weiteres !- Zeichen vorgestellt
werden. Die Funktion ist deshalb notwendig, weil Formeln beim Editieren automatisch in Großbuchstaben
gewandelt werden.
1.6.2.4.6.5 Funktionen mit zwei Operanden
Funktion Bedeutung Operand1; Operand2
MAX Maximum
MIN Minimum
ATRV Attribut lesen Attributstyp; Variable
TMVL Zeitmerkmal lesen Wert; Offset
PERP Ewige Rente Kennzahl; Zinssatz
Einheit für Operand Zinssatz ist Prozent

(10% werden als 10 dargestellt, nicht
als 0.1).
C2DATE Datum ermitteln Zeitmerkmal;'S'tart- / 'E'ndwert
Geben Sie für den Start- und Endwert

einer Periode S bzw. E ein.
CONCAT Operanden konkatenieren <Operand1>; <Operand2>
VARI i-ter Variablenwert Variable; Index
ROUND Rundung Kennzahl; Nachkommastellen
Planungskonzepte
 Hinweis
● Die Funktion PERP berechnet die ewige Rente aus einem Grundkapital nach der folgenden Formel:
Ergebnis = Kennzahlwert * (Zinssatz / 100)
● Bei der Funktion C2DATE muss für den Endwert E und für den Startwert einer Periode S angegeben
werden.
1.6.2.4.6.6 Funktionen mit drei Operanden
Funktion Bedeutung Operand1; ... ; Operand3
DISC Abzinsung Kennzahl; Zinssatz; Jahre
Formel für Abzinsung eines Betrags: Er

gebnis = Kennzahlwert / ((1 + Zins
satz / 100) ** Jahre)
DECD Degressive Abschreibung Startwert; Prozentsatz; Jahre
Die Funktion berechnet nach folgendem

Algorithmus:
1. "Führe [Anzahl der Jahre] mal aus:

Zwischenwert = Zwischenwert +
(Startwert - Zwischenwert) * Pro
zentsatz / 100"
2. Ergebnis = Startwert - Zwischen
wert
ATRVT Zeitabhängiges Attribut lesen Attributstyp; Variable; Datum
SUBSTR Teilstring auslesen Variable; Offset; Länge
REPLACE Zeichen ersetzen Quellstring; Muster; Ersatz
 Hinweis
● Die Funktion DISC zinst einen Betrag nach der folgenden Formel ab:
Ergebnis = Kennzahlwert / ( ( 1 + Zinssatz / 100 ) ** Jahre )
● Die Funktion DECD berechnet eine degressive Abschreibung nach dem folgenden Algorithmus:
1. Führe Jahre mal aus.
Zwischenwert = Zwischenwert + ( Startwert - Zwischenwert ) * Prozentsatz / 100.
2. Ergebnis = Startwert - Zwischenwert
Planungskonzepte
1.6.2.4.6.7 Funktionen mit vier Operanden
DECL Lineare Abschreibung Startwert; Restwert; Prozentsatz; Jahre
Die Berechnung einer linearen Ab Darstellung für Operand Prozentsatz:

schreibung geschieht mit der Formel: 10% als 10, nicht als 0.1
Ergebnis = Startwert - ((Startwert -
Restwert) * Prozentsatz / 100 * Jahre).
 Hinweis
Die Funktion DECL berechnet eine lineare Abschreibung nach der folgenden Formel:
Ergebnis = Startwert - ( ( Startwert - Restwert ) * Prozentsatz / 100 * Jahre )
1.6.2.4.6.8 Funktion mit fünf Operanden
CURC Währungsumrechung Betrag; Datum; Kurstyp; Quellwährung;

Zielwährung
 Hinweis
Die Funktion CURC rechnet einen Betrag in eine andere Zielwährung um. Beachten Sie, dass es bei
Kennzahlen vom Typ Gleitkomma zu kleinen Rundungsdifferenzen kommen kann, da intern mit neun
Nachkommastellen gerechnet wird.
1.6.2.4.6.9 Funktion ohne Operanden
Funktion Bedeutung
OBJV Merkmalswert lesen
Planungskonzepte
1.6.2.4.7 Bedingte Anweisungen
Verwendung
Sie realisieren bedingte Anweisungen mit Hilfe der IF-Anweisung. Auf eine IF-Anweisung können weitere
bedingte Anweisungen mit ELSEIF folgen. Zur Behandlung der restlichen Fälle innerhalb einer Kette von
bedingten Anweisungen gibt es die ELSE-Anweisung. Das Schema sieht also in etwa wie im folgenden Beispiel
aus.
 Beispiel
IF <Ausdruck1>.
<Anweisung1>.
ELSEIF <Ausdruck2>.
<Anweisung2>.
ELSE.
<Anweisung3>.
ENDIF.
Ausdrücke innerhalb der IF-Anweisung bestehen aus Operanden zzgl. Variablen und Konstanten,
Vergleichsoperatoren und logischen Operatoren (siehe Operatoren und Funktionen [Seite 52]).
 Hinweis
Beachten Sie, dass Konstanten nur auf der rechten Seite eines Vergleichsoperators stehen dürfen.
 Beispiel
Um den Spezialfall zu überprüfen, ob ein Operand <oper1> den Initialwert hat, können Sie schreiben:
IF <oper1> IS INITIAL. oder IF <oper1> = '#'.
 Beispiel
Exemplarische Konstruktion mit logischen Operatoren: IF NOT <oper1> < <oper2> AND <oper3> =
<oper4> OR <oper5> > <oper2>.
Arbeiten mit zeichenartigen Operanden
Für das Arbeiten mit zeichenartigen Operanden stehen Ihnen noch folgende Operatoren zur Verfügung.
Operator Bedeutung in Ausdruck
CP ( C ontains P attern) Die gesamte Zeichenfolge c1 entspricht dem Muster c2.
Im Muster c2 können auch Wildcards enthalten sein, dabei steht '*'

für eine beliebige Zeichenfolge, '+' für ein beliebiges Zeichen.
Planungskonzepte
Operator Bedeutung in Ausdruck
CO ( C ontains O nly) c1 enthält nur Zeichen aus der Zeichenmenge c2.
Wenn c1 oder c2 vom internenTyp C ist, dann geht das Feld in seiner
vollen Länge in den Vergleich ein, d.h. Leerzeichen am Ende werden
berücksichtigt.
Wenn c1 vom Typ STRING und leer ist, dann ist der Ausgang des Ver
gleichs stets positiv.
Wenn c2 vom Typ STRING und leer ist, dann ist der Ausgang des Ver
gleichs stets negativ, außer c1 ist ebenfalls ein leerer String.
CA ( C ontains A ny) c1 enthält mindestens ein Zeichen aus der Zeichenmenge c2.
Wenn c1 oder c2 vom Typ C ist, dann geht das Feld in seiner vollen
Länge in den Vergleich ein, d.h. Leerzeichen am Ende werden berück
sichtigt.
Wenn c1 oder c2 vom Typ STRING und leer ist, dann ist der Ausgang
des Vergleichs stets negativ.
CS ( C ontains S tring) c1 enthält die Zeichenfolge c2. Wenn das jeweilige Feld vom Typ C ist,
dann werden abschließende Leerzeichen in c1 und c2 ignoriert.
Eine leere Zeichenfolge c2 (also nur Leerzeichen beim Typ C, bzw.

der leere String beim Typ STRING) ist in jeder beliebigen Zeichen
folge c1 enthalten, so auch in der leeren Zeichenfolge selbst. Ande
rerseits gibt es keine nichtleere Zeichenfolge c2, die in einer leeren
Zeichenfolge c1 enthalten ist.
1.6.2.4.8 Schleifenkonstrukte
Verwendung
DO-Schleife
● Anweisungen, die zwischen DO und ENDDO stehen, werden beliebig oft wiederholt.
● Die Schleife wird durch die Anweisung EXIT unterbrochen.
● Die Zahl der Schleifendurchläufe kann durch eine Konstante oder eine Variable vom Typ I gesteuert
werden: DO <n>TIMES.
FOREACH-Schleife
● Mit der Anweisung FOREACH <Variable>. wird über alle Werte einer Variablen iteriert. Es handelt sich
um die Merkmalswerte, die in den Bewegungsdaten des aktuellen Datenobjektes vorhanden sind (also
nicht unbedingt um alle Stammdatenwerte, die für das Merkmal definiert sind). Dieses Schleifenkonstrukt
wird durch die Anweisung ENDFOR abgeschlossen.
● Die Merkmalswerte werden aufsteigend sortiert abgearbeitet. Wenn Sie Kombinationen von
Merkmalswerten benötigen, können Sie die Anweisung in der Form FOREACH <Variable1,Variable2>.
Planungskonzepte
einsetzen. Dieses Konstrukt liefert die vorhandenen Kombinationen von Merkmalswerten des aktuellen
Datenobjektes.
 Hinweis
Anmerkungen zum Laufzeitverhalten: Vor dem Eintritt in die FOREACH-Schleife werden alle im
Datenobjekt vorhandenen Merkmalswerte gesammelt und sortiert, danach werden diese
Merkmalswerte in der FOREACH-Schleife nacheinander geliefert. Wenn in der Schleife ein neuer Wert
erzeugt und in die Bewegungsdaten geschrieben wird, wird dieser erst bei der nächsten FOREACH-
Schleife berücksichtigt.
Das FOREACH-Konstrukt kostet viel Rechenzeit und sollte möglichst sparsam eingesetzt werden.
Überlegen Sie auch immer sorgsam, ob Sie anstelle von zwei geschachtelten Schleifen nur ein
Konstrukt der Art FOREACH <Variable1, Variable2>. benutzen können, da das Laufzeitverhalten
hierdurch verbessert wird.
● Weitere Varianten der FOREACH-Schleife:

○ Mit FOREACH <Variable> IN REFDATA kann über alle Merkmalswerte, die in den Referenzdaten
vorhanden sind, iteriert werden.
○ Mit FOREACH <Variable> IN SELECTION kann über alle Merkmalswerte des aktiven
Planungsfilters iteriert werden.
○ Mit FOREACH <Variable> IN VARIABLE Var kann über alle Merkmalswerte einer globalen
Variablen Var iteriert werden.
Beispiel
Das folgende Beispiel zeigt ein schlechtes Programm:
 Beispielcode
DATA COUNTRY TYPE 0BPS_CNTRY.

DATA PRODUCT TYPE 0BPS_PRODU.
FOREACH COUNTRY.
FOREACH PRODUCT.
FOREACH FISCPER.
{REVENUE, COUNTRY, PRODUCT, FISCPER} = {REVENUE, COUNTRY, PRODUCT,
FISCPER} * 2.
ENDFOR.
ENDFOR.
ENDFOR.
Das folgende Beispiel zeigt ein besseres Programm: Hier wird darauf geachtet, dass neue Werte nur dann
erzeugt werden, wenn sie von Null verschieden sind. Da die Menge der Werte, die in den Variablen PRODUCT
und FISCPER auftauchen können, nicht aktualisiert werden muss, spart dies sehr viel Rechenzeit. Eine solche
Aktualisierung tritt jedes mal dann ein, wenn die beiden Schleifen FOREACH PRODUCT. und FOREACH
FISCPER. neu durchlaufen werden. Wenn durch eine Formel Nullwerte erzeugt werden, schreibt das System
diese nicht in den internen Puffer zurück. Diese Nullwerte sind also für nachfolgende Planungsfunktionen oder
die manuelle Planung nicht sichtbar. Andererseits wird auch nicht vorhandenen Daten der Wert 0 zugewiesen.
Nullwerte müssen also nicht explizit erzeugt werden.
Planungskonzepte
 Beispielcode

FOREACH COUNTRY.
FOREACH PRODUCT.
FOREACH FISCPER.
IF {REVENUE, COUNTRY, PRODUCT, FISCPER} <> 0.
{REVENUE, COUNTRY, PRODUCT, FISCPER} = {REVENUE, COUNTRY,
PRODUCT, FISCPER} * 2.
ENDIF.
ENDFOR.
ENDFOR.
ENDFOR.
Abschließend zeigt das folgende Beispiel den empfohlenen Weg zu programmieren:
 Beispielcode

FOREACH COUNTRY, PRODUCT, FISCPER.
IF NOT {REVENUE, COUNTRY, PRODUCT, FISCPER} IS INITIAL.
{REVENUE, COUNTRY, PRODUCT, FISCPER} = {REVENUE, COUNTRY, PRODUCT,
FISCPER} * 2.
ENDIF.
ENDFOR
1.6.2.4.9 Meldungsausgabe
Verwendung
Sie können Meldungen ausgeben lassen mittels der Anweisung MESSAGE Tnnn(<Klasse>). oder MESSAGE
Tnnn(<Klasse>) WITH <Operand1> ... <Operand4>.
● T ist der Typ der Meldung ('E' = Fehler, 'I' = Information). Wenn Fehler vom Typ 'E' ausgelöst werden,
werden die Ergebnisse der Planungsfunktion nicht in den internen Bewegungsdatenpuffer übernommen.
● nnn ist eine dreistellige Nummer.
● Klasse ist die Nachrichtenklasse.
● Optional können maximal 4 Operanden zusätzlich mitgegeben werden. Operanden können entweder
Variablen oder in Hochkommata eingeschlossene Strings sein.
Die Meldungen werden gesammelt und nach der Ausführung der Funktion angezeigt.
 Empfehlung
Wir empfehlen, für Fehlermeldungen eine eigene Nachrichtenklasse anzulegen statt von SAP ausgelieferte
Meldungen zu verwenden. Beachten Sie, dass Sie die eigene Nachrichtenklasse vom Testsystem in das
Produktivsystem transportieren müssen.
Planungskonzepte
1.6.2.4.10 Aufruf von Funktionsbausteinen
Verwendung
Mit der Anweisung CALL FUNCTION können Sie Funktionsbausteine aufrufen. Tragen Sie hierzu die Namen der
Funktionsbausteine in Transaktion SM30 in die Tabelle RSPLF_FDIR ein.
Den Funktionsbausteinen können EXPORTING-, IMPORTING- und CHANGING-Parameter übergeben werden. Bei
den Parametern muss es sich um einfache Typen handeln ( F, I, D, STRING und Typen von Merkmalen und
Attributen). Klassenreferenzen, Strukturen und Tabellenparameter sind nicht zugelassen.
Alle nichtoptionalen IMPORTING-Parameter eines Funktionsbausteines müssen versorgt werden.
Falls der Funktionsbaustein eine Ausnahme auslöst, müssen Sie mit dem Konstrukt MESSAGE ... RAISING
arbeiten. Auch klassenbasierte Ausnahmen sind zugelassen. Die Meldungen des Funktionsbausteins werden
ins Protokoll übernommen.
Beispiel
Im folgenden Beispiel wird der Funktionsbaustein UPF_DISTR_RATE_GET aufgerufen.
 Quellcode

DATA FISCYEAR TYPE 0FISCYEAR.
DATA RATE TYPE F.
DATA KYF TYPE KEYFIGURE_NAME.
FOREACH FISCYEAR, KYF.
FISCPER = OBJV( ).
CALL FUNCTION UPF_DISTR_RATE_GET
EXPORTING
I_FISCPER = FISCPER
I_VERSION = 'OPTIMISTIC'
IMPORTING
E_RATE = RATE.
{KYF,FISCYEAR} = { KYF, FISCYEAR } * RATE.
ENDFOR.
Das folgende Beispiel zeigt den Einsatz der Anweisung MESSAGE ... RAISING im Falle einer ausgelösten
Ausnahme.
 Beispielcode
FUNCTION UPF_DISTR_RATE_GET.
*"----------------------------------------*"
*"Lokale Schnittstelle:
*"IMPORTING
*" REFERENCE(I_FISCPER) TYPE /BI0/OIFISCPER
*" REFERENCE(I_VERSION) TYPE STRING DEFAULT 'OPTIMISTIC'
*"EXPORTING*" REFERENCE(E_RATE) TYPE F
*" REFERENCE(E_FISCYEAR) TYPE /BI0/OIFISCYEAR
*"EXCEPTIONS
*" ERROR*"----------------------------------------*"
Planungskonzepte
DATA: L_FISCPER_3 TYPE N LENGTH 3.
L_FISCPER_3 = I_FISCPER+4(3).
IF I_VERSION = 'OPTIMISTIC'.
E_RATE = l_FISCPER_3 / 5.
ELSE.
E_RATE = l_FISCPER_3 / 7.
ENDIF.
E_FISCYEAR = I_FISCPER(4).
IF L_FISCPER_3 IS INITIAL OR E_FISCYEAR IS INITIAL.
MESSAGE E001(UPF) WITH 'Initiale Werte'(TIV) RAISING ERROR.
ENDIF.
ENDFUNCTION.
1.6.2.4.11 Interne Tabellen
Sie können interne Tabellen definieren und verwenden:
TABLE INTTAB { YEAR TYPE 0CALYEAR KEY, ZAHL TYPE F, COSTCENTER TYPE 0COSTCENTER }.
Interne Tabellen bestehen aus Feldern. Für diese Felder können Datentypen verwendet werden, die für
Variablen erlaubt sind. Ein Feld gefolgt von KEY ist ein Schlüsselfeld. Es muss mindestens ein Schlüsselfeld
vorhanden sein sowie ein Feld, das kein Schlüsselfeld ist. Pro Schlüssel gibt es in der Tabelle nur einen Eintrag.
Tabellen können durch die Zuordnung eines Werts gefüllt werden:
INTTAB.{ZAHL,2011} = 25.
INTTAB.{ COSTCENTER, 2013 } = 00004711.
Sie können folgendermaßen auf Werte zugreifen:
{ 0VCPL_INT, 2013 } = INTTAB.{ ZAHL, 2013 }.
Folgende Sonderfunktionen sind für interne Tabellen verfügbar:
● Anzahl der Zeilen festlegen: CNT = LINES( INTTAB ).

● Angeben, ob ein Wert existiert: CNT = EXISTS( INTTAB.{ 2013 } ). Die Variable CNT ist vom Typ I.
Sie ist auf den Wert 1 gesetzt, wenn der Eintrag existiert oder auf 0 gesetzt, wenn der Eintrag nicht
existiert.
● Bestimmten Wert löschen: DELETE( INTTAB.{ 2014 } ).
● Alle Werte löschen: CLEAR INTTAB.
● FOREACH-Schleife für Werte: FOREACH YEAR IN INTTAB.
1.6.2.4.12 Unterroutinen
Komplexe Formeln können Sie mit Unterroutinen modularisieren, d.h. besser strukturieren.
Unterroutinen beginnen mit FORM und enden mit ENDFORM. Nach FORM folgt ein eindeutiger Name. Sie
können IMPORTING- und CHANGING-Parameter übergeben. Die IMPORTING-Parameter werden als Wert
übergeben, ändern sich also nicht ausserhalb, wenn ihnen in der Routine ein anderer Wert zugewiesen wird. Bei
den Parametern müssen Sie einen Typ angeben. Bei internen Tabellen nehmen Sie eine Tabelle, die bereits mit
TABLE definiert wurde.
Planungskonzepte
Das folgende Beispiel zeigt eine Unterroutine COLLECT_REFDATA und die vorausgehenden DATA- und TABLE-
Deklarationen einer Planungsfunktion vom Typ Formel.
 Beispielcode
...
DATA SUM_REF TYPE F.
DATA REF_CNT TYPE I.
DATA PLUS_CNT TYPE I.
DATA MINUS_CNT TYPE I.
...
TABLE REFDATA_TAB {
PRO TYPE 0PRODUCT KEY,
REF TYPE F
}.
FORM COLLECT_REFDATA IMPORTING REF_RATIO TYPE KEYFIGURE_NAME
CHANGING REF_TAB TYPE REFDATA_TAB
SUM_REF TYPE F
PLUS_CNT TYPE I
MINUS_CNT TYPE I.
DATA M_PRODUCT TYPE 0PRODUCT.
DATA REF_DATA TYPE F.
SUM_REF = 0.
PLUS_CNT = 0.
MINUS_CNT = 0.
CLEAR REF_TAB.
FOREACH M_PRODUCT IN REFDATA.
IF M_PRODUCT <> '#'.
REF_DATA = { REF_RATIO, M_PRODUCT | 0VERSION = V00 }.
IF REF_DATA <> 0.
REF_TAB.{ REF, M_PRODUCT } = REF_DATA.
SUM_REF = SUM_REF + REF_DATA.
IF REF_DATA > 0.
PLUS_CNT = 1.
ELSEIF REF_DATA < 0.
MINUS_CNT = 1.
ENDIF.
ENDIF.
ENDIF.
ENDFOR.
ENDFORM.
Die Unterroutine COLLECT_REFDATA hat IMPORTING- und CHANGING-Parameter. Der Parameter REF_TAB
ist eine interne Tabelle. Der zugehörige Typ REFDATA_TAB wird zuvor in der Formel als Tabelle deklariert. In
Unterroutinen kann nicht auf Variablen aus der Formel zugegriffen werden. Alle notwendigen Informationen
müssen als Parameter übergeben werden.
Der Aufruf in der Formel sieht wie folgt aus:
 Beispielcode
COLLECT_REFDATA( REF_RATIO, REFDATA_TAB, SUM_REF, PLUS_CNT, MINUS_CNT ).
1.6.2.4.13 INCLUDE von Formeln
Über die INCLUDE-Anweisung können Sie Formeln aus verschiedenen Aggregationsebenen einschließen.
Planungskonzepte
 Beispielcode
INCLUDE FOX1.
Folgende Teile werden aus der Formel übernommen:
● Definition von internen Tabellen als Typen

● InfoProvider
● Forms
 Beispielcode
DATA CALDAY TYPE 0CALDAY.

TABLE KURSTAB { DAY TYPE 0CALDAY KEY, KURS TYPE F }.
FORM INIT_KTYPE IMPORTING KTYPE TYPE ZJSKTYP.

DATA CALDAY TYPE 0CALDAY.
FOREACH CALDAY.
{0KURS,CALDAY,KTYPE} = 0.
ENDFOR.
ENDFORM.
…
INIT_KTYPE( 06 ).
INIT_KURSTAB( 05, KURSTAB ).
CALCULATE_KURS( 06, KURSTAB, 10 ).
Nur die Definition von TABLE KURSTAB und die FORM INIT_KTYPE können von eingeschlossenen
Planungsfunktionen referenziert werden. Globale DATA-Anweisungen und die Formel selbst werden nicht
berücksichtigt.
1.6.2.4.14 Zugriff auf InfoProvider
In der BW-integrierten Planung können zusätzlich Daten aus beliebigen Aggregationsebenen und nicht
planbaren DataStore-Objekten gelesen werden. Diese werden mit dem Info Provider-Statement deklariert.
 Beispiel
INFOPROVIDER DSO_REF.
Der Zugriff erfolgt mit dem folgenden Ausdruck:
{ 0VCPL_INT, 2013 } = DSO_REF.{ 0VCPL_QUAV, YEAR }.
Beim Zugriff wird vor die geschweiften Klammern der Name des InfoProviders und ein `.` geschrieben. Im
Beispiel ist 0CALYEAR das zu verändernde Merkmal. Bei InfoProvidern müssen in den geschweiften Klammern
alle zu verändernden Merkmale sowie diejenigen Merkmale angegeben werden, die nicht in der
Aggregationsebene vorhanden sind. Auf Blockmerkmale kann mit der bekannten Notation zugegriffen werden.
{ 0VCPL_INT, 2013 } = DSO_REF.{ 0VCPL_QUAV, YEAR | 0PLANT = PLANT }.
Planungskonzepte
Sie können keine Werte setzen. Das System kann aber über die Werte, die einem Block zugeordnet werden,
iterieren:
FOREACH YEAR IN DSO_REF.

{ 0VCPL_INT, 2013 } = { 0VCPL_INT, 2013 } + DSO_REF.{ 0VCPL_QUAV, YEAR }.
ENDFOR.
Welche Daten das System liest, bestimmt es wie bei den Referenzdaten aus der Formel. So erweitert das
System z.B. die Selektion für das Merkmal 0PLANT um den Wert PLANT01, wenn in der Formel folgendes
steht:
{ 0VCPL_INT, 2013 } = DSO_REF.{ 0VCPL_QUAV, YEAR | 0PLANT = PLANT01 }.
Mit dem KEEP- und dem ENHANCE-Statement können Sie die Selektion der Referenzdaten beeinflussen.
● Indem Sie das KEEP-Statement verwenden, können Sie vermeiden, dass das System die Selektion der
Referenzdaten löscht:
KEEP REFDATA SELECTION FOR INFOPROVIDER DSO_REF FOR 0CALYEAR.
● Um explizit zusätzliche Referenzdaten anzufordern, können Sie das ENHANCE-Statement benutzen:
ENHANCE REFDATA SELECTION FOR INFOPROVIDER DSO_REF

FOR 0CALYEAR: 2015, 2016.
Sie können auch globale Variablen in einer solchen Liste verwenden:
ENHANCE REFDATA SELECTION FOR INFOPROVIDER DSO_REF

FOR 0CALYEAR: 2015, 2016, YEARVAR.
1.6.2.4.15 Beispiele für Formelanwendungen
Verwendung
Zur Veranschaulichung der Anwendung von Formeln werden folgende Beispiele erläutert:
1. Preisplanung
2. Preisplanung mit Preisen in den Stammdaten
3. Quotenplanung
4. Kopieren mit Bedingung auf dem Wert einer Kennzahl
5. Kopieren mit Bedingung und Iteration über Kennzahlname
6. Plausibilitätsprüfung von Daten
7. Rollierende Planung
8. Abschreibung
9. Rechnen mit Datentyp 'D'
Planungskonzepte
10. Arbeiten mit Zeichenketten
1. Preisplanung
In Version 1 wird geplant, in Version 2 sind die Preise in den Bewegungsdaten abgelegt. Die zu verändernden
Merkmale sind:
● Version ( 0VERSION)
● Geschäftsjahr ( 0GJAHR)
● Kunde ( 0CUSTOMER)
Die Sätze haben die Besonderheit, dass die Merkmale Kunde und Geschäftsjahr den Wert nicht zugeordnet
haben und deshalb in die Menge der zu verändernden Merkmale aufgenommen werden müssen. Weiterhin
muss es für jedes zu planende Objekt in Version 1 ein Objekt in Version 2 geben, über das der Preis ermittelt
werden kann. Wenn zu einem Artikel kein Preis geplant ist, wird eine Meldung ausgegeben. Die Berechnung
wird nur ausgeführt, wenn die Kombination {MENGE,1, GJAHR,CUSTOMER} geplant, also > 0 ist.
 Beispielcode
DATA CUSTOMER TYPE 0CUSTOMER.

DATA GJAHR TYPE 0GJAHR.
DATA ARTICLE TYPE 0ARTICLE.
IF {PREIS,2,#,#} = 0.
ARTICLE = OBJV( ).
MESSAGE I001(/SEM/003) WITH ARTICLE.
ELSE.
FOREACH GJAHR, CUSTOMER.
IF {MENGE,1,GJAHR,CUSTOMER} > 0.
{ERLOS,1,GJAHR,CUSTOMER} = {MENGE,1,GJAHR,CUSTOMER} * {PREIS,2,#,#}.
ENDIF.
ENDFOR.
ENDIF.
Das Fehlen des Merkmals Artikel ( 0ARTICLE) in der Liste der zu verändernden Merkmale scheint
überraschend, da sich die Preise, mit denen gerechnet wird, sich auf 0ARTICLE beziehen. Unter ausdrücklicher
Einbeziehung des Merkmals 0ARTICLE würde das Beispiel wie folgt aussehen:
 Beispielcode

DATA GJAHR TYPE 0GJAHR.
FOREACH ARTICLE, GJAHR, CUSTOMER.
IF {PREIS,2,#,#,ARTICLE} = 0.
ELSE.
IF {MENGE,1,GJAHR,CUSTOMER,ARTICLE} > 0.
{ERLOS,1,GJAHR,CUSTOMER,ARTICLE} = {MENGE,1,GJAHR,CUSTOMER,ARTICLE} *
{PREIS,2,#,#,ARTICLE}.
ENDIF.
ENDIF.
ENDFOR.
Tatsächlich ist das Merkmal 0ARTICLE für die Formel überflüssig, da die Werte des Merkmals nicht geändert
werden. Bei der Berechnung des geplanten Erlöses zeigt sich, dass auf beiden Seiten des Zuweisungsoperators
jeweils auf denselben Artikel verwiesen wird.
Planungskonzepte
 Empfehlung
Wir empfehlen, in einem solchen Fall das Merkmal nicht in die Menge der zu verändernden Merkmale
aufzunehmen, da es für die Berechnung nicht benötigt wird, aber beim Zugriff auf die Werte Performance
kostet. Ein weiteres Mittel, um die Formel zu beschleunigen, besteht darin, den Wert des Elementes
{PREIS,2,#,#} in einer Hilfsvariablen zu speichern und dann mit dieser zu arbeiten. Falls der Wert eines
Merkmals benötigt wird, um Fehlermeldungen auszugeben oder um Attributwerte zu ermitteln, kann mit
der Funktion OBJV() der Wert gelesen werden.
Die Formel kann noch kürzer aufgeschrieben werden, wenn auf die Referenzdaten explizit zugegriffen wird. Es
gibt dann außer Kennzahlname keine zu verändernden Merkmale. Die Formel wird je Datensatz durchlaufen.
Eine FOREACH-Schleife über zu verändernde Merkmale ist damit überflüssig.
 Beispielcode

IF {PREIS | 0VERSION = 2,0GJAHR = #,0CUSTOMER = #} = 0.
ARTICLE = OBJV( ).
ELSE.
ERLOS = MENGE * { PREIS | 0VERSION = 2,0GJAHR = #,0CUSTOMER = #}.
ENDIF.
2. Preisplanung mit Preisen in den Stammdaten
Wie sieht die Preisplanung aus, wenn der Preis in den Stammdaten abgelegt ist? Mit Hilfe der Funktion OBJV
holen wir uns den Wert des Artikels. Mit Hilfe der Funktion ATRV wird der Wert des Attributes 0PRICE gelesen.
Die Funktion ATRV hat im einfachen Fall zwei Argumente. Das erste Argument muss der Name eines
Stammdatenattributes sein, das zweite Argument eine Variable. Mit Hilfe des Variablenwertes wird in der
Stammdatentabelle der Wert des Attributs gelesen. Bei geklammerten Merkmalen sind folgende Fälle zu
unterscheiden:
● Wenn die übergeordneten Merkmale zu verändernde Felder sind, müssen die Werte dieser Merkmale der
Funktion in Form von Variablen mitgegeben werden. Die Zahl der Argumente der Funktion richtet sich in
diesem Fall danach, wie viele Felder mitgegeben werden müssen.
● Wenn die übergeordneten Merkmale nicht in der Menge der zu verändernden Felder enthalten sind, werden
die Werte automatisch aus den Werten des aktuellen Päckchens versorgt. Im folgenden Beispiel ist nur der
Kennzahlname ein zu veränderndes Merkmal.
 Beispielcode

ARTICLE = OBJV().
ERLOS = ATRV( '0PRICE', ARTICLE ) * MENGE.
3. Quotenplanung
Zu verändernde Merkmale sind Kennzahlname, Version (0VERSION) und Kunde (0CUSTOMER).
 Beispielcode
DATA GESERLOS TYPE F.

DATA GESMENGE TYPE F.
FOREACH CUSTOMER.
Planungskonzepte
GESERLOS = GESERL0S + {ERLOS,2,CUSTOMER}.
GESMENGE = GESMENGE + {MENGE,2,CUSTOMER}.
ENDFOR.
FOREACH CUSTOMER.
{ERLOS,1,CUSTOMER} = {MENGE,1,CUSTOMER} * GESERLOS / GESMENGE.
ENDFOR.
4. Kopieren mit Bedingung auf dem Wert einer Kennzahl
Zu veränderndes Merkmal ist Version. Als Merkmal für Bedingungen ist der Kennzahlname ausgewählt worden.
Als Wert für den Kennzahlnamen wurde ERLOS ausgewählt. Die folgende Formel kopiert den Erlös von Version 1
nach Version 2, falls der Erlös in Version 1 größer als 500 ist. In diesem Beispiel können wir nicht die
Planungsfunktion vom Typ Kopieren [Seite 73] einsetzen, da hier keine Bedingungen auf Kennzahlwerten
formuliert werden können. In der Regel ist es vorteilhafter, anstelle von Formeln die speziellen
Planungsfunktionen zu verwenden, da diese effizienter implementiert sind.
 Beispielcode
IF {1} > 500.

{2} = {1}.
ENDIF.
5. Kopieren mit Bedingung und Iteration über Kennzahlname
Zu verändernde Merkmale sind Kennzahlname und Version. Im Gegensatz zum obigen Beispiel werden jetzt
alle Kennzahlen nach Version 2 kopiert, falls der Erlös größer als 500 ist. Um die Zuweisung nicht für alle
Kennzahlen schreiben zu müssen, definieren wir eine Variable RATIO vom Typ KEYFIGURE_NAME und iterieren
mit Hilfe des FOREACH-Konstruktes über alle Kennzahlen der Planungsebene.
 Beispielcode
DATA RATIO TYPE KEYFIGURE_NAME.

IF { ERLOS, 1 } > 500.
FOREACH RATIO.
{ RATIO, 2 } = { RATIO, 1 }.
ENDFOR.
ENDIF.
6. Plausibilitätsprüfung von Daten
Zu verändernde Merkmale sind Kennzahlname, Version und Artikel. Wir überprüfen, ob der geplante Erlös
mindestens 90 Prozent des Erlöses der Version 1 erreicht. Wenn die Grenze unterschritten wird, gibt das
System eine Warnmeldung aus.
 Beispielcode

DATA MINERLOS TYPE F.
FOREACH ARTICLE.
MINERLOS = { ERLOS, 1, ARTICLE } * 0.9.
IF { ERLOS, 2, ARTICLE } < MINERLOS.
* Der geplante Erlös für Artikel &1 unterschreitet den vorgegebenen
Mindesterlös
MESSAGE I034(ZSEM) WITH ARTICLE.
ENDIF.
ENDFOR.
Planungskonzepte
7. Rollierende Planung
Zu verändernde Merkmale sind Version und Geschäftsjahr/Periode. Die Ist-Daten der aktuellen Periode werden
in die Planversion kopiert. Die Differenz wird auf die restlichen Perioden verteilt. Die aktuelle Periode wird aus
einer Variablen ermittelt.
 Beispielcode
DATA ACTPER TYPE FISCPER.

DATA FISCPER TYPE FISCPER.
DATA SUM TYPE F.
DATA DELTA TYPE F.
* Periode aus der Variablen mit dem technischen Namen PERIODE lesen
ACTPER = VARV( 'PERIODE' ).
* Summe zum Gewichten besorgen
FOREACH FISCPER.
IF FISCPER > ACTPER.
SUM = SUM + { 1, FISCPER }.
ENDIF.
ENDFOR.
* Delta zwischen Planwert und Istwert bestimmen
DELTA = {1, ACTPER} - {0,ACTPER}.
* Planwert auf Istwert setzen
{1,ACTPER} = {0, ACTPER}.
* Delta gewichtet verteilen
FOREACH FISCPER.
IF FISCPER > ACTPER.
{1,FISCPER} = {1,FISCPER} + DELTA * {1,FISCPER} / SUM.
ENDIF.
ENDFOR.
8. Abschreibung
Zu verändernde Merkmale sind Kennzahlname und Geschäftsjahr. Es wird der Wert der Kennzahl 0AMOUNT für
fünf Jahre ermittelt. Anschaffungspreis ist 1000. Restwert ist 100. Abschreibungsprozentsatz ist 20 Prozent. Es
wird linear abgeschrieben. Bei diesem Beispiel steht nicht die Funktion DECL (lineare Abschreibung) im
Mittelpunkt des Interesses, sondern die Funktion TMVL. Diese Funktion hat als erstes Argument den Wert eines
Zeitmerkmales und als zweites Argument einen Offset. Der Offset gibt an, den wievielten nächstgrößeren Wert
die Funktion liefern soll. Es ist auch möglich, negative Offsets zu übergeben. Dann werden die entsprechenden
kleineren Werte geliefert. Es wäre nicht möglich, mit einer FOREACH-Schleife den gleichen Effekt zu erzielen, da
in den Bewegungsdaten nicht alle Jahre vorhanden sein müssen.
 Beispielcode
DATA JAHRE TYPE I.

DATA GJAHR TYPE 0FISCYEAR.
GJAHR = VARV( 'ACTYEAR' ).
DO.
JAHRE = JAHRE + 1.
GJAHR = TMVL( GJAHR, 1 ).
{0AMOUNT, GJAHR} = DECL( 1000, 100, 20, JAHRE).
IF JAHRE = 5.
EXIT.
ENDIF.
ENDDO.
9. Rechnen mit Datentyp 'D'
Es ist auch möglich, mit dem Datentyp 'D' Berechnungen durchzuführen. Im folgenden ist ein kleines Beispiel
aufgeführt. In der FOREACH-Schleife werden in D1 das Datum des ersten Tages in FISPCER und in D2 der letzte
Planungskonzepte
Tag in FISPCER ermittelt. Daraufhin wird in I1 die Differenz zwischen D2 und D1 gebildet und zwei Tage
subtrahiert. I1 ist vom Typ I. Wenn die Datumsangaben in D1 und D2 ungültig sind, kommt als Resultat 0
heraus. Wenn mit Feldern vom Typ D gerechnet wird, werden die konstanten Operanden daraufhin überprüft,
ob es sich um gültige Datumsangaben handelt. Deshalb konnten wir nicht I1 = D2 - D1 - 2. schreiben,
sondern mussten eine Hilfsvariable I2 verwenden.
 Beispielcode
DATA D1 TYPE D.
DATA D2 TYPE D.
DATA I1 TYPE I.
DATA I2 TYPE I.
FOREACH FISCPER.
* Calculate 1st day of FISCPER
D1 = C2DATE( FISCPER, S ).
* Calculate last day of FISCPER
D2 = C2DATE( FISCPER, E ).
* Calculate the difference between last and 1st day minus two days
I2 = 2.
I1 = D2 - D1 - I2.
MESSAGE I001(UPF) WITH 'DIFFERENCE' I1.
ENDFOR.
10. Arbeiten mit Zeichenketten
Im folgenden Beispiel wird geprüft, ob die Merkmale Geschäftsjahr/Periode ( 0FISCPER), Geschäftsjahr

( 0FISCYEAR) und dreistellige Buchungsperiode ( 0FISCPER3) zueinander konsistent gefüllt sind.
Geschäftsjahr/Periode ist sieben Zeichen lang; in den ersten vier Zeichen steht das Geschäftsjahr, in den
Zeichen fünf bis sieben ist die Buchungsperiode abgelegt. Mit Hilfe der Funktion SUBSTR (Merkmalswert,
Offset, Länge) werden aus dem Wert von Geschäftsjahr/Periode die entsprechenden Werte ausgelesen.
Falls der Merkmalswert von Geschäftsjahr/Periode initial ist, wird er mit dem verketteten Wert von
Geschäftsjahr und Buchungsperiode gefüllt. Dazu wird die Funktion CONCAT benutzt.
 Beispielcode

DATA FISCPER_CMP TYPE 0FISCPER.
DATA YEAR TYPE 0FISCYEAR.
DATA PER TYPE 0FISCPER3.
DATA PER_CMP TYPE 0FISCPER3.
DATA YEAR_CMP TYPE 0FISCYEAR.
DATA KYFNM TYPE KEYFIGURE_NAME.
YEAR = OBJV( ).
PER = OBJV( ).
FISCPER_CMP = CONCAT( YEAR, PER3 ).
FOREACH KYFNM, FISCPER.
IF FISCPER IS INITIAL.
{KYFNM,FISCPER_CMP} = {KYFNM,FISCPER}.
ELSE.
PER_CMP = SUBSTR( FISCPER, 4, 3 ).
YEAR_CMP = SUBSTR( FISCPER, 0, 4 ).
IF YEAR <> YEAR_CMP OR PER <> PER_CMP.
* Fehlermeldung
MESSAGE E021(/SEM/003) WITH YEAR YEAR_CMP PER PER_CMP.
ENDIF.
ENDIF.
ENDFOR.
Planungskonzepte
1.6.2.5 Formel mit Verarbeitung von Nullsätzen
Der Funktionstyp Formel mit Verarbeitung von Nullsätzen (0RSPL_FORMULA_ZERO) unterscheidet sich vom
Planungsfunktionstyp Formel (0RSPL_FORMULA) darin, dass auch Sätze, bei denen alle Kennzahlen gleich Null
sind (Nullsätze), verarbeitet werden.
Verwendung
Mit diesem Planungsfunktionstyp können auch Nullsätze erzeugt werden. Weil es sich bei Nullsätzen um
fehlerhafte Sätze handeln kann, die storniert wurden, prüft das System beim Lesen der Daten von der
Datenbank alle Sätze gegen die Merkmalsbeziehungen und verarbeitet nur die gültigen Sätze.
Dies gilt für Filterdaten, Referenzdaten und Daten, die aus anderen InfoProvidern hinzugelesen werden. Falls
der Parameter RS_DEBUGLEVEL auf einen Wert > 1 gesetzt wird, wird auch in der Datenbank-Prozessierung
ermittelt, wieviele Sätze übersprungen werden. Sonst werden entsprechende Meldungen nur ausgegeben,
wenn die Planungsfunktion auf dem Anwendungsserver ausgeführt wird.
1.6.2.6 Kennzahlwerte setzen
Verwendung
Mit dem Funktionstyp Kennzahlwerte setzen können Sie Werte für Kennzahlen setzen und nach Referenzdaten
verteilen lassen.
Kennzahlwerte setzen
Um Kennzahlwerte zu setzen, können Sie eine Selektionsbedingung auf Blockmerkmalen, den Namen der
Kennzahl und den zu setzenden Wert eingeben.
Verteilung nach Referenzdaten
Die Verteilung wird nicht ausgeführt, wenn kein Merkmal als zu verändernd ausgewählt ist.
Für die Verteilung der Kennzahlwerte stellt das System verschiedene Parameter zur Verfügung. Diese
Parameter entsprechen den Parametern zur Auswahl der Referenzdaten des Funktionstypes Verteilung nach
Referenzdaten.
Vergleich mit dem Funktionstyp Verteilung nach Referenzdaten
Der Funktionstyp Kennzahlwerte setzen arbeitet mit Nullsätzen. Nullsätze sind Sätze, deren Kennzahlwerte aus
Sicht der Aggregationsebene Null sind. Das unterscheidet diesen Funktionstyp vom Funktionstyp Verteilung
nach Referenzdaten, der keine Nullsätze verarbeitet. Wenn keine Referenzdaten vorhanden sind, also auf
vorhandene Objekte gleichverteilen eingestellt wird, können Planungsfunktionen des Typs Kennzahlwerte
setzen auf eine größere Zahl von Objekten gleichverteilen als Planungsfunktionen vom Typ Verteilen nach
Referenzdaten.
Planungskonzepte
Verteilung nach Referenzdaten [Seite 94]
1.6.2.7 Kopieren
Verwendung
Mit dem Funktionstyp Kopieren können Sie die Kennzahlwerte von bestehenden Merkmalskombinationen auf
andere Merkmalskombinationen kopieren.
 Beispiel
Wenn Sie z.B. die Werte aus dem Jahr 2015 nach 2017 kopieren möchten, ohne ein anderes Merkmal zu
verändern, setzen Sie das Kennzeichen wird verändert einzig für das Merkmal Jahr.
Über die Tabelle zur Kennzahlauswahl können Sie festlegen, welche Kennzahlen kopiert werden sollen.
Über die Tabelle Von- und Nachwerte für den Kopiervorgang können Sie entweder einen einfachen
Kopiervorgang oder mehrere Kopiervorgänge innerhalb einer Planungsfunktion anlegen.
Der Funktionstyp erlaubt auch komplizierte Kopiervorgänge: Sowohl die Von- als auch die Nach-Werte können
beliebige Merkmalseinschränkungen auf den zu verändernden Merkmalen sein. Das System summiert dabei
die Werte der Kennzahlen auf der Von-Seite stets über alle Sätze des Blockes, die der Merkmalseinschränkung
entsprechen; auf der Nach-Seite schreibt es stets die Summe auf jede einzelne Merkmalskombination.
Sie können auch Werte von einem Von-Wert in mehrere Nach-Werte kopieren.
 Beispiel
Sie kopieren von Jahr "2015" und Version "IST" auf die Kombination {"2016", "PLAN01"} und auf die
Kombination {2017, "PLAN02"}.
Der Funktionstyp liest und schreibt Nullsätze.
Es gelten folgende Regeln:
● Die Von-Werte werden als Referenzdaten gelesen und müssen demnach nicht im Filter enthalten sein, der
der Planungsfunktion übergeben wird.
● Die Nach-Werte werden verändert; daher müssen sie im übergebenen Filter enthalten sein.
● Die Kennzahlwerte der Nach-Werte werden beim Kopieren immer überschrieben. Dies gilt auch, wenn die
Von-Werte leer sind.
● Wenn es zu einer Merkmalseinschränkung auf der Von-Seite keine Werte für einen Block gibt, wird der
Teilvorgang nicht ausgeführt.
● Auf der Nach-Seite werden für die angegebenen Merkmalseinschränkungen Kombinationen erzeugt. Dies
geschieht in Konsistenz mit den Stammdaten und den auf den InfoProvidern definierten
Merkmalsbeziehungen. Wenn das System dabei für einen Block und einen Teilvorgang kein Ziel findet,
werden keine Daten erzeugt.
● Wenn ein Ziel in mehreren Teilvorgängen genannt wird, enthält es nach dem Ausführen der Funktion die
entsprechende Summe.
Planungskonzepte
Die Kopierfunktion bildet auch Blöcke aus den Referenzdaten.
Kopieren (ohne Berücksichtigung von Nullsätzen) [Seite 74]
1.6.2.7.1 Kopieren (ohne Berücksichtigung von Nullsätzen)
Verwendung
Mit dem Funktionstyp Kopieren (ohne Berücksichtigung von Nullsätzen) können Sie die Kennzahlwerte von
bestehenden Merkmalskombinationen auf andere Merkmalskombinationen kopieren. Im Unterschied zum
Funktionstyp Kopieren werden allerdings keine Nullsätze gelesen oder geschrieben.
 Hinweis
Eine Planungsfunktion vom Typ Kopieren (ohne Berücksichtigung von Nullsätzen) kann hinsichtlich der
Performance besser sein als eine vom Typ Kopieren, da in der Regel weniger Merkmalsbeziehungen geprüft
werden müssen.
Kopieren [Seite 73]
1.6.2.8 Löschen
Verwendung
Mit dem Funktionstyp Löschen können Sie die Kennzahlwerte der ausgewählten Datensätze löschen.
Dabei werden keine Merkmalswerte verändert. In der Merkmalsverwendung können Sie daher Merkmale nur
als Bedingungsmerkmale auswählen.
Über eine Tabelle können Sie die zu löschenden Kennzahlen auswählen.
Planungskonzepte
DSO-Sätze löschen [Seite 75]
1.6.2.8.1 DSO-Sätze löschen
Verwendung
Mit dem Funktionstyp DSO-Sätze löschen werden Sätze aus einem Direct Update DataStore-Objekt physisch
gelöscht. Im Falle eines DataMart DataStore-Objektes werden sie auf Null gesetzt.
 Achtung
Beachten Sie, dass entweder die Aggregationsebene, auf der Sie die Planungsfunktion anlegen, alle Felder
des DataStore-Objektes enthält, oder dass die nicht enthaltenen Felder durch die Ableitung aufgefüllt
werden.
Merkmale, die Datenfelder sind, müssen als Kennzahl verwendet werden können. Dies können Sie in der
Pflege des DataStore-Objektes einstellen. Die Kennzahlen (und nicht die Datenfelder) müssen dann in die
Aggregationsebene aufgenommen werden, die als Basis für die Planungsfunktion dient.
Löschen [Seite 74]
1.6.2.9 Löschen ungültige Kombinationen
Verwendung
Mit dem Funktionstyp Löschen ungültige Kombinationen können Sie alle Kennzahlwerte sämtlicher Sätze
löschen, deren Kombination von Merkmalswerten nicht den Merkmalskombinationen entsprechen, die auf
dem zugrunde liegenden planungsrelevanten InfoProvider definiert sind.
 Hinweis
Beachten Sie folgende Bedingung: Eine Planungsfunktion diesen Typs kann nur auf einer
Aggregationsebene angelegt werden, die direkt auf einem planungsrelevanten InfoProvider als Datenbasis
angelegt ist (sog. einfache Aggregationsebene, siehe Aggregationsebene [Seite 23]). Die
Aggregationsebene muss alle in Aggregationsebenen gültigen InfoObjects des InfoProviders enthalten.
Planungskonzepte
 Hinweis
Da es im normalen Betrieb eines Direct Update DataStore-Objektes nicht möglich ist,

Merkmalskombinationen, also Sätze, komplett zu löschen, setzt die Planungsfunktion lediglich alle
Kennzahlen auf Null zurück. Ebenso verhält es sich bei einem lokalen Provider im BW Workspace.
1.6.2.9.1 Physisches Löschen ungültiger Daten im

DataStore-Objekt
Verwendung
Mit dem Funktionstyp Physisches Löschen ungültiger Daten im DSO können Sie die Kennzahlwerte sämtlicher
Sätze physisch löschen, deren Kombination von Merkmalswerten nicht den Merkmalskombinationen
entsprechen, die auf dem zugrunde liegenden planungsrelevanten Direct Update DataStore-Objekt definiert
sind. Im Falle eines DataMart DataStore-Objektes werden sie auf Null gesetzt.
 Achtung
des DataStore-Objektes enthält, oder dass die nicht enthaltenen Felder durch die Ableitung aufgefüllt
werden.
Löschen ungültige Kombinationen [Seite 75]
1.6.2.10 Prognose
Verwendung
Um die zukünftige Entwicklung von Kennzahlen vorherzusagen, verwenden Sie Prognoseverfahren. Der
Standard-Planungsfunktionstyp Prognose stellt verschiedene Strategien und statistische Verfahren zur
Verfügung, um aus historischen Daten Prognosewerte für die Zukunft zu berechnen.
Planungskonzepte
Integration
Die Strategien und Verfahren dieses Planungsfunktionstyps basieren auf denselben statistischen Verfahren,
wie sie in der Bedarfsplanung zum Einsatz kommen.
 Hinweis
Weitere Informationen über die Prognose im Rahmen der Bedarfsplanung finden Sie im Internet unter
http://help.sap.com SAP Business Suite SAP Supply Chain Management SAP APO 3.1 Application
Help Absatzplanung (Demand Planning) Prozess der Absatzplanung Definition/Neudefinition von
Prognosemodellen Gesamtprognoseprofil anlegen Univariate Prognose .
Voraussetzungen
● Es müssen Vergangenheitsdaten verfügbar sein, die bei der Prognoserechnung als historische Daten
eingehen.
● Die Aggegrationsebene, in deren Kontext Sie eine Prognose-Planungsfunktion anlegen, muss mindestens
ein Zeitmerkmal enthalten (z.B. Geschäftsjahr/Periode). Die Prognose arbeitet mit nur einem Zeitmerkmal.
Nur Werte dieses Merkmales werden verändert. Die anderen Merkmale und insbesondere redundante
Zeitmerkmale werden durch die Prognosefunktion nicht angepasst. Zeitmerkmale müssen allerdings
immer zueinander konsistente Werte annehmen. So passt der Wert 2017 vom Merkmal Kalenderjahr
(0CALYEAR) zu den Werten 01.2017 bis 12.2017 vom Merkmal Kalenderjahr/Monat (0CALMONTH). Falls
jetzt aber Werte über eine Jahresgrenze hinweg prognostiziert werden sollen, muss das Kalenderjahr in
den prognostizierten Sätzen unterschiedliche Werte annehmen. Diese leistet die Planungsfunktion nicht,
wohl aber die Ableitung, die automatisch redundante Zeitmerkmale richtig auffüllt.
 Hinweis
Beachten Sie, dass Sie in der Aggregationsebene keine redundanten Zeitmerkmale aufnehmen wie z.B.
Kalenderjahr/Monat (InfoObject 0CALMONTH) und Kalenderjahr (InfoObject 0CALYEAR) oder
Geschäftsjahr/Periode (InfoObject 0FISCPER) und Geschäftsjahr (InfoObject 0FISCYEAR). Nehmen
Sie nur dasjenige Zeitmerkmal in der Aggregationsebene auf, das die feinste Granularität aufweist.
In den genannten Beispielen verwenden Sie also 0CALMONTH bzw. 0FISCPER; die Werte des
übergeordneten Zeitmerkmals 0CALYEAR bzw. 0FISCYEAR werden dann automatisch abgeleitet.
Funktionsumfang
Der Planungsfunktionstyp Prognose umfasst verschiedene univariate Prognoseverfahren. Hierbei wird

ausschließlich der zeitliche Verlauf (die Zeitreihe) der gewählten Prognosekennzahl berücksichtigt, d.h. es
gehen keine weiteren Informationen in die Prognoserechnung ein, die den Verlauf der Kennzahl erklären
könnten.
Zeitreihenverläufe
Planungskonzepte
Sie können Prognosen für die folgenden Typen von Zeitreihen erstellen:
Konstanter Verlauf
Die Vergangenheitsdaten sind im Wesentlichen konstant und weichen nur geringfügig von einem stabilen
Mittelwert ab. Diesen Grundwert stellt in der folgenden Grafik eine rote Linie dar:
Trendförmiger Verlauf
Die Zeitreihe steigt bzw. fällt kontinuierlich. Diesen Trend veranschaulicht in der folgenden Grafik eine rote
Linie:
Saisonaler Verlauf
Planungskonzepte
Die Werte zeigen ein periodisch (z.B. im Jahresrhythmus) sich wiederholendes Muster. Es gibt einen stabilen
Mittelwert. Diesen Grundwert stellt in der folgenden Grafik eine rote Linie dar:
Trendsaisonaler Verlauf
Die Zeitreihe ist eine Kombination von trendförmigem und saisonalem Verlauf. Die saisonalen Schwankungen
verstärken sich dabei bei steigendem Trend.
Sporadischer Verlauf
Die Zeitreihe hat zu den meisten Zeitpunkten den Wert Null. Die Werte ungleich Null schwanken um einen
Mittelwert.
Planungskonzepte
Prognosestrategien
Die Prognosestrategie bestimmt, welche Prognoseverfahren zum Einsatz kommen. Bei der Wahl einer
geeigneten Prognosestrategie sollten Sie sich am Verlauf der Zeitreihe orientieren. Den verschiedenen
Prognoseverfahren liegen unterschiedliche Prognosemodelle (Zeitreihenmodelle) zugrunde. Sie erzeugen
daher unterschiedliche Ergebnisse.
Es stehen Ihnen die folgenden Prognosestrategien zur Verfügung:
● Durchschnitt
● Gleitender Durchschnitt
● Gewichteter gleitender Durchschnitt
● Lineare Regression
● Saisonale lineare Regression
● Einfache exponentielle Glättung (Konstantmodell)
● Einfache exponentielle Glättung mit Alpha-Optimierung (Konstantmodell)
● Lineare exponentielle Glättung (Trendmodell)
● Saisonale exponentielle Glättung (Saisonmodell)
● Trendsaisonale exponentielle Glättung (Trend-Saisonmodell)
● Verfahren nach Croston
● Automatische Modellauswahl
Mit der Prognosestrategie Automatische Modellauswahl können Sie durch das System dasjenige
Prognoseverfahren auswählen lassen, dessen zugrunde liegendes Prognosemodell am besten zu der Zeitreihe
der Vergangenheitswerte passt.
Wenn Sie bereits wissen, dass ein bestimmtes Prognosemodell gut zum Zeitreihenverlauf passt, oder wenn Sie
ein Prognoseverfahren aus anderen Gründen explizit vorgeben möchten, können Sie alternativ ein bestimmtes
Prognoseverfahren auswählen.
Zusätzliche Funktionen für die Prognosestrategien
Die Prognosestrategien bieten zusätzlich folgende Funktionen und Möglichkeiten:
● Ausreißerkorrektur
● Statistische Kennzahlen protokollieren
● Anfängliche Nullwerte ignorieren
Für die exponentielle Glättung:
● Optimierung der Glättungsfaktoren für die Exponentielle Glättung
Für Prognosemodelle mit Trendkomponente:
● Trenddämpfung
Lücken im Prognose- oder Vergangenheitszeitraum
Sowohl im Prognose- als auch Vergangenheitszeitraum können Lücken entstehen. Diese Lücken werden
beachtet, d.h. die selektierten Zeitpunkte werden nicht lückenlos aneinander gereiht. Lücken im
Prognosezeitraum werden so behandelt, dass die Werte dieser Zeitpunkte nicht verändert werden. Lücken im
Vergangenheitszeitraum gehen mit dem Wert 0 in die Prognoseberechnung ein.
 Hinweis
Beachten Sie, dass die Zeitpunkte vor dem ersten Prognosezeitpunkt zur Vergangenheit gehören.
Planungskonzepte
 Beispiel
Sie möchten Prognosedaten erzeugen für die Monate 1-3 und 5-7 (Monat 4 wird separat behandelt). Das
System berechnet Prognosewerte für alle Monate 1-7, lässt aber den Monat 4 unverändert. Bei einem
linearen Trend im Prognoseergebnis mit Werten 1010, 1020 ergibt sich folgendes Ergebnis:
Monat Planung
1 1010
2 1020
3 1030
5 1050
6 1060
7 1070
Prognosestrategien [Seite 81]

Automatische Modellauswahl [Seite 85]
Ausreißerkorrektur [Seite 87]
Trenddämpfung [Seite 88]
Statistische Kennzahlen protokollieren [Seite 89]
Anfängliche Nullwerte ignorieren [Seite 90]
1.6.2.10.1 Prognosestrategien
Die Prognosestrategie bestimmt, auf welche Weise Prognosewerte berechnet werden.
Verwendung
Allen Prognosestrategien liegen statistische Prognoseverfahren und Prognosemodelle zugrunde, welche die
Zeitreihe mathematisch beschreiben. Die Methoden der exponentiellen Glättung sind die derzeit am weitesten
verbreiteten Zeitreihenverfahren. Wenn Sie erwarten, dass sich die Entwicklung der Vergangenheitswerte auch
in Zukunft fortsetzt, wählen Sie ein Prognosemodell, welches gut zu dem bisherigen Zeitreihenverlauf passt.
Planungskonzepte
 Hinweis
Mit der Strategie Automatische Modellauswahl können Sie durch das System dasjenige Prognosemodell
der exponentiellen Glättung auswählen lassen, welches am besten zu dem Verlauf der Vergangenheitswerte
passt.
Funktionsumfang
Folgende Prognosestrategien stehen zur Verfügung:
Durchschnitt: Der Prognosewert ergibt sich aus dem arithmetischen Mittel der Vergangenheitswerte.
Optionale Prognoseparameter:
Gleitender Durchschnitt: Der Prognosewert wird entsprechend der Ordnung berechnet.
Obligatorischer Prognoseparameter:
● Ordnung gleit. Durchschnitt:

Die Ordnung des gleitenden Durchschnittes ist eine Zahl N, welche die Länge des Zeitintervalls für die
Durchschnittsberechnung bestimmt, d.h. die Anzahl zeitlich aufeinander folgender Vergangenheitswerte.
Der Prognosewert ergibt sich einfach als Durchschnitt der letzten N Vergangenheitswerte.
Geben Sie eine positive Zahl für die Ordnung ein.
Gewichteter gleitender Durchschnitt: Bei der Berechnung des gleitenden Durchschnittes erhält jeder
Vergangenheitswert ein bestimmtes Gewicht.
Obligatorische Prognoseparameter:
● Ordnung gleit. Durchschnitt:

Die Ordnung des gleitenden Durchschnittes ist eine Zahl N, welche die Länge des Zeitintervalls für die
Durchschnittsberechnung bestimmt, d.h. die Anzahl zeitlich aufeinander folgender Vergangenheitswerte.
Geben Sie eine positive Zahl für die Ordnung ein.
● Gewichtungsfaktoren:
Die Gewichtungsfaktoren geben das Verhältnis an, mit dem die einzelnen Vergangenheitswerte bei der
Durchschnittsberechnung eingehen. Wichtig ist die Reihenfolge der Gewichte: Der Gewichtungsfaktor mit
der Nummer 1 bezieht sich auf die Vorperiode, Gewichtungsfaktor 2 auf die Vorvorperiode usw.
 Beispiel
Sie möchten eine Prognose auf der Grundlage monatlicher Werte erstellen und wählen den
gewichteten gleitenden Durchschnitt der Ordnung 6. Hierbei möchten Sie die letzten (jüngsten)
Planungskonzepte
Monatswerte stärker gewichten als die älteren. Die Vergangenheitsdaten kommen aus den Monaten 5
bis 10. Die sechs Gewichtungsfaktoren und der jeweils relevante Monat lauten wie folgt:
Nr. Gewichtungsfaktor Bezugsmonat
1 3,00 10
2 2,00 9
3 2,00 8
4 1,00 7
5 1,00 6
6 1,00 5
Lineare Regression: Einfache lineare Regression (Verfahren der kleinsten Quadrate).
● Trenddämpfung
Saisonale lineare Regression: Der saisonalen linearen Regression liegt dasselbe statistische Verfahre
zugrunde, wie es in der Bedarfsplanung zum Einsatz kommt.
 Hinweis
Weitere Informationen finden Sie im Internet unter http://help.sap.com/ SAP Business Suite SAP
Supply Chain Management SAP APO 3.1 Application Help Absatzplanung (Demand Planning)
Prozess der Absatzplanung Definition/Neudefinition von Prognosemodellen Gesamtprognoseprofil
anlegen Univariate Prognose Prognosestrategien Saisonale lineare Regression
Obligatorischer Prognoseparameter: Perioden pro Saison
● Trenddämpfung
Einfache exponentielle Glättung (Konstantmodell): Die einfache exponentielle Glättung ist geeignet, falls die
Vergangenheitsdaten einen konstantförmigen Verlauf aufweisen.
Planungskonzepte
Einstellungen Glättungsfaktoren: Alpha (Grundwert)
Einfache exponentielle Glättung mit Alpha-Optimierung (Konstantmodell): Das Verfahren entspricht der
oben genannten "einfachen exponentiellen Glättung"; zusätzlich berechnet das System jedoch noch den
Glättungsfaktor Alpha. Hierbei wird Alpha in dem Intervall mit der eingestellten Schrittweite variiert und jeweils
eine Prognoserechnung (für den Vergangenheitszeitraum) durchgeführt. Das Optimum für Alpha ist derjenige
Wert, für den das Prognose-Ergebnis den kleinsten Fehler aufweist.
Einstellungen Glättungsfaktoren: Optimierungsgröße, Alpha von, Alpha bis, Alpha-Schrittweite
Lineare exponentielle Glättung (Trendmodell): Die Prognose erfolgt nach dem Verfahren von Holt und ist
geeignet, falls sich die Vergangenheitswerte durch einen steigenden bzw. fallenden Trend beschreiben lassen.
Einstellungen Glättungsfaktoren: Alpha (Grundwert), Beta (Trendwert),
● Trenddämpfung
Saisonale exponentielle Glättung (Saisonmodell): Diese Strategie ist geeignet, falls Ihre Vergangenheitswerte
saisonale Schwankungen (z.B. jährlich) um einen konstanten Grundwert aufweisen.
Einstellungen Glättungsfaktoren: Alpha (Grundwert), Gamma (Saisonkomponente)
Trendsaisonale exponentielle Glättung: Die Prognose erfolgt nach dem multiplikativen Verfahren von Winter/
Holt und ist geeignet, falls die Vergangenheitswerte saisonal um einen steigenden bzw. fallenden Trend
schwanken. Dabei verstärkt sich die Schwankung mit steigendem Trend.
 Beispiel
Eisverkauf im Sommer: Angenommen, der Eisverkauf steigt jährlich im Trend um 10%, dann führt ein
saisonaler Anstieg in jedem Sommer um 30% zu immer stärkeren absoluten Schwankungen.
Einstellungen Glättungsfaktoren: Alpha (Grundwert), Beta (Trendwert), Gamma (Saisonkomponente)
● Trenddämpfung
Planungskonzepte
Croston-Methode
Die Croston-Methode wurde speziell für sporadische Verläufe entwickelt. Dieses Verfahren wendet die
exponentielle Glättung an, um einen mittleren zeitlichen Abstand zwischen den Werten ungleich Null der
Zeitreihe zu berechnen.
 Hinweis
Weitere Informationen finden Sie im Internet unter http://help.sap.com/ SAP Business Suite SAP
Supply Chain Management SAP APO 3.1 Application Help Absatzplanung (Demand Planning)
Prozess der Absatzplanung Definition/Neudefinition von Prognosemodellen Gesamtprognoseprofil
anlegen Univariate Prognose Prognosestrategien Croston-Methode .
Prüfen Sie, ob sich eventuell durch Aggregation der Daten die Lücken in der Zeitreihe beseitigen lassen, so dass
Verfahren eingesetzt werden können, die trendförmige oder saisonale Verläufe berücksichtigen. Eine solche
Aggregation lässt sich z.B. erreichen, indem ein gröberes Zeitmerkmal gewählt wird (monats- statt
tagesgenaue Betrachtung) oder indem die Prognosen für Produktgruppen anstatt für Einzelprodukte
berechnet werden.
Automatische Modellauswahl [Seite 85]

Ausreißerkorrektur [Seite 87]
Trenddämpfung [Seite 88]
Statistische Kennzahlen protokollieren [Seite 89]
Anfängliche Nullwerte ignorieren [Seite 90]
1.6.2.10.2 Automatische Modellauswahl
Verwendung
Über die automatische Modellauswahl können Sie das System bestimmen lassen, welches Prognosemodell am
besten zu Ihren Vergangenheitsdaten passt.
 Empfehlung
Wir empfehlen die automatische Modellauswahl, wenn Sie den Verlauf Ihrer Vergangenheitsdaten nicht
kennen, die Entwicklung Ihrer Daten nicht einschätzen können oder wenn Sie kein Modell vorgeben
möchten.
Planungskonzepte
Funktionsumfang
Das System führt eine Reihe von Tests durch, anhand derer es das zu verwendende Modell ermittelt (siehe
Prognosestrategien [Seite 81]). Falls die Wahl auf ein Modell der exponentiellen Glättung fällt, optimiert das
System die relevanten Glättungsfaktoren ( Alpha, Beta, Gamma).
 Hinweis
Beachten Sie, dass die automatische Modellauswahl einen höheren Rechenaufwand bedingt. Dies gilt
insbesondere für die trendsaisonalen Modelle. Der Rechenaufwand hängt ferner von der Größe des
Suchraumes und der Feinheit der eingestellten Schrittweiten ab.
Aktivitäten
1. Das System testet zunächst auf sporadische Vergangenheitsdaten, indem es die Anzahl der Perioden
bestimmt, die in der Vergangenheitskennzahl keine Daten enthalten. Wenn diese Anzahl mehr als 66% der
Gesamtanzahl der Perioden beträgt, verwendet das System automatisch die Croston-Methode.
2. Das System testet dann auf weißes Rauschen. Wenn es weißes Rauschen gibt, verwendet es automatisch
die Konstantmethode.
3. Wenn beide Tests negativ sind, testet das System auf Saison- und Trendeffekte.
1. Zunächst entfernt das System vorhandene Trends. Um auf Saisoneffekte zu testen, bestimmt das
System den Autokorrelationskoeffizienten. Wenn der Autokorrelationskoeffizient größer als 0,3 ist,
dann ist der Test positiv.
2. Um auf Trendeffekte zu testen, bestimmt das System einen Trendsignifikanzparameter. Wenn der
Saisontest positiv ist, entfernt es zunächst mögliche Saisoneffekte. Wenn keine Saisoneffekte
festgestellt werden, führt es diesen Test über die Anzahl der Vergangenheitsperioden, minus 2, aus
Wenn Saisoneffekte festgestellt werden, führt es den Test über die Anzahl der Perioden in einer Saison,
plus 1, aus.
 Hinweis
Da die Ergebnisse dieser beiden Tests vorgeben, welche Modelle das System im nächsten Schritt
prüft, hat der Parameter Perioden pro Saison große Bedeutung. Wenn Ihre Vergangenheitsdaten
z.B. eine Saison mit sieben Perioden enthält und Sie den Wert "3" für Perioden pro Saison
eingeben, wird der Saisontest wahrscheinlich negativ sein. Saisonmodelle werden dann nicht
geprüft, sondern nur Trend- und Konstantmodelle.
4. Das System führt anschließend Prognosen mit den ausgewählten Modellen durch (siehe die nachfolgende
Tabelle) und berechnet dabei sämtliche Fehlermaße. Bei Modellen, die Prognoseparameter ( Alpha, Beta,
Gamma) nutzen, werden diese Parameter in den Bereichen und Schrittgrößen variiert, wie diese im
Prognoseprofil angegeben sind.
Test auf weißes Test auf sporadi Saisontest Trendtest

Rauschen sche Daten
Croston-Modell X
Planungskonzepte
Trendmodell X
Saisonmodell X
Trend-Saison A A
Lineare Regression o X
Saisonale lineare Regres A A

sion
Die Zeichen in der Tabelle haben folgende Bedeutung:

X - Das Modell wird verwendet, wenn der Test positiv ist.
A - Das Modell wird verwendet, wenn alle Tests positiv sind.
o - Das Modell wird verwendet, wenn dieser Test negativ ist.
Das Konstantmodell läuft immer, ausgenommen dann, wenn der Test auf sporadische Daten positiv ist. In
diesem Fall wird (als spezieller Typ des Konstantmodells) nur das Croston-Modell verwendet.
Das System wählt dann das Modell mit denjenigen Parametern, die das niedrigste Fehlermaß ergeben, wie
dies im Feld Fehlermaß des Prognoseprofils ausgewählt wurde.
1.6.2.10.3 Ausreißerkorrektur
Verwendung
"Ausreißer" sind ungewöhnliche Werte, die sich durch das gewählte Prognosemodell nicht erklären lassen. Das
Prognoseergebnis kann stark von ihnen beeinflusst werden.
Das System kann Ausreißerwerte in den Vergangenheitsdaten identifizieren und ersetzen. Dabei berechnet das
Prognoseverfahren Prognosewerte im Vergangenheitszeitraum und vergleicht diese mit den
Vergangenheitswerten. Wenn die Differenz, das sog. Residuum, einen bestimmten Grenzwert überschreitet,
wird der Vergangenheitswert durch den Ex-post-Prognosewert des zugehörigen Zeitpunkt ersetzt. Nach dieser
Korrektur wird die Prognoseberechnung mit den berichtigten Vergangenheitsdaten erneut durchgeführt.
Für die Bestimmung des Grenzwertes können Sie den Sigma-Faktor festlegen.
Integration
Die Ausreißerermittlung hängt von dem Prognosemodell ab, weil der erwähnte Prognosewert nach einem
Modell und dem zu diesem gehörenden Algorithmus berechnet wird.
Planungskonzepte
Funktionsumfang
Im Rahmen der Prognosefunktion werden Ausreißer in den Vergangenheitswerten durch den Sigma-Faktor
definiert. Je größer der Sigma-Faktor ist, desto toleranter ist das System gegenüber ungewöhnlichen Werten,
d.h. desto weniger Ausreißer werden ermittelt.
Der Sigma-Faktor fac bestimmt die Ausreißerermittlung in der folgenden Weise: Ein Beobachtungswert y ist ein
Ausreißer, falls die Differenz e zu dem Prognosewert größer als fac *s ist. Hierbei bezeichnet s die
Standardabweichung der Residuen.
Aktivitäten
Aktivieren Sie die Ausreißerkorrektur, wenn Sie der Meinung sind, dass Ausreißer gemäß der Definition der
Prognosefunktion ungünstige Auswirkungen auf das Prognoseergebnis haben.
Vermeiden Sie die Ausreißerkorrektur, wenn ungewöhnliche Werte bei der Prognose stets berücksichtigt
werden sollen.
1.6.2.10.4 Trenddämpfung
Verwendung
Für Prognosemodelle mit einer Trendkomponente ( Lineare Regression, Trendmodelle der exponentiellen
Glättung mit bzw. ohne Saisonalität, ggf. Automatische Modellauswahl) können Sie den Trend für die in der
Zukunft liegenden Prognosewerte dämpfen, indem Sie einen Trenddämpfungsfaktor festlegen.
Nutzen Sie den Trenddämpfungsfaktor, wenn Sie bei Ihren Prognosen annehmen möchten, dass sich die
Steigerungsraten aus der Vergangenheit in der Zukunft abschwächen oder verstärken werden.
Funktionsumfang
Der Trenddämpfungsfaktor ist eine Zahl, die bei der Berechnung jedes Prognosewertes mit dem Trendwert
(Steigerungsrate) zum jeweiligen Zeitpunkt multipliziert wird. Dadurch wird eine Steigung des langfristigen
Trends immer weiter abgeschwächt bzw. verstärkt:
● Mit einem Trenddämpfungsfaktor kleiner als 1 lässt sich eine Art Sättigungseffekt modellieren. Der
Trendwert nähert sich exponentiell dem Wert 0 an.
 Beispiel
Ein Trenddämpfungsfaktor von 0.9 verringert die Wachstumsrate für jede Periode rekursiv um 10%.
Wenn z.B. die Stückzahl verkaufter Fahrzeuge derzeit um 1000 Stück in jeder Periode wächst, beträgt
das Wachstum der Verkaufszahl nach der nächsten Periode noch 0.9 * 1000 = 900 Stück, nach der
übernächsten Periode noch 0,9 * 900 = 810 Stück usw.
Planungskonzepte
● Für den umgekehrten Effekt können Sie einen Trenddämpfungsfaktor größer als 1 eingeben.
Aktivitäten
Um eine Trenddämpfung durchzuführen, wählen Sie diese Option; legen Sie einen Trenddämpfungsfaktor
entsprechend Ihren Erwartungen fest.
1.6.2.10.5 Statistische Kennzahlen protokollieren
Verwendung
Diese Funktion protokolliert statistische Informationen zur Prognoseberechnung.
Nach dem Ausführen der Prognosefunktion zeigt das System die entsprechenden statistischen Informationen
ebenso wie die Fehlermeldungen zur Prognoseberechnung als Meldungen (im Protokoll) an.
Funktionsumfang
Folgende statistische Informationen werden protokolliert:
● Fehlersumme
● Mittlerer absoluter Fehler (MAD)
● Mittlerer absoluter prozentualer Fehler (MAPE)
● Mittlerer prozentualer Fehler (MPE)
● Mittlerer quadratischer Fehler (MSE)
● Wurzel des mittleren quadratischen Fehlers (RMSE)
● Anzahl der Ausreißer (bei aktiver Ausreißerkorrektur)
● Gewähltes Prognosemodell (bei der automatischen Modellauswahl)
● Glättungsfaktoren (bei Optimierung von Glättungsfaktoren)
Aktivitäten
Wählen Sie diese Option, um statistische Informationen zum Prognoseergebnis zu protokollieren.
Planungskonzepte
1.6.2.10.6 Anfängliche Nullwerte ignorieren
Verwendung
Mit dieser Funktion können Sie festlegen, ob aufeinander folgende Nullwerte zu Beginn des ausgewählten
Vergangenheitszeitraums bei der Prognose berücksichtigt werden sollen.
 Beispiel
Sie möchten Prognosewerte für Ihre Produkte berechnen. Als Vergangenheitszeitraum dienen die letzten
24 Monate. Die Zeitreihe von Produkten, die es erst seit einigen Monaten gibt, beginnt deshalb mit einer
längeren Folge von Nullwerten. Sie möchten nicht, dass dadurch die Prognosewerte beeinflusst werden,
und wählen die Option Anfängliche Nullwerte ignorieren.
Aktivitäten
Wählen Sie diese Option, wenn anfängliche Nullwerte von der Prognoseberechnung ausgeschlossen werden
sollen.
1.6.2.11 Protokoll einer Prozesskette ausgeben
Mit dem Funktionstyp Protokoll einer Prozesskette ausgeben(0RSPL_GET_PC_LOG) können Sie das Protokoll
der letzten gestarteten Prozesskette auslesen.
Das System gibt Übersichtsinformationen und nicht die Details aus. Auch bei Planungsfunktionen diesen Typs
werden die Daten im Filter weder gelesen noch gesperrt.
Prozesskette starten [Seite 90]
1.6.2.12 Prozesskette starten
Mit dem Funktionstyp Prozesskette starten (0RSPL_START_PROCESS) können Sie aus der Planung heraus eine
Prozesskette starten.
Als Parameter benötigen Sie nur den Namen der Prozesskette.
Die Prozesskette können Sie im Customizing hinterlegen. Die Planungsfunktion muss wie üblich zusammen mit
einem Filter gestartet werden, aber es wird keine Sperre gesetzt und es werden auch keine Daten gelesen.
Planungskonzepte
Die Prozesskette läuft asynchron ab.
Um das Ergebnis der Prozesskette zu erhalten, verwenden Sie den Funktionstyp Protokoll einer Prozesskette
ausgeben (0RSPL_GET_PC_LOG).
Protokoll einer Prozesskette ausgeben [Seite 90]
1.6.2.13 Umbuchen
Verwendung
Mit dem Funktionstyp Umbuchen können Sie (ähnlich wie beim Kopieren [Seite 73]) die Kennzahlwerte
bestehender Merkmalskombinationen auf andere Kombinationen buchen. Im Unterschied zum Kopieren
werden die Kennzahlwerte der Von-Werte jedoch gelöscht. Ein einführendes Beispiel finden Sie unter
Planungsfunktionen [Seite 33].
Über die Tabelle zur Kennzahlauswahl können Sie festlegen, welche Kennzahlen umgebucht werden sollen.
Über die Tabelle Von- und Nach-Werte für den Umbuchungsvorgang können Sie entweder einen einfachen
Umbuchvorgang oder mehrere Umbuchvorgänge innerhalb einer Planungsfunktion anlegen.
● Sowohl die Von- als auch die Nach-Werte der Umbuchungsvorgänge müssen Einzelwerte sein.
● Sowohl die Von- als auch die Nach-Werte werden verändert und müssen daher im Filter enthalten sein, der
● Beim Umbuchen werden die Kennzahlwerte immer auf die Nach-Werte addiert.
1.6.2.13.1 DSO-Daten umbuchen und Quelldaten physisch

löschen
Verwendung
Mit dem Funktionstyp DSO-Daten umbuchen und Quelldaten physisch löschen können Sie die Kennzahlwerte
bestehender Merkmalskombinationen auf andere Kombinationen buchen. Sämtliche Quelldaten aus einem
Direct Update DataStore-Objekt werden gelöscht. Im Falle eines DataMart DataStore-Objektes werden die
Quelldaten storniert.
Planungskonzepte
 Achtung
des DataStore-Objektes enthält oder dass die nicht enthaltenen Felder durch die Ableitung aufgefüllt
werden.
Umbuchen [Seite 91]
1.6.2.14 Umbuchen nach Merkmalsbeziehungen
Verwendung
Mit dem Funktionstyp Umbuchen nach Merkmalsbeziehungen können Sie Bewegungsdaten so umbuchen,
dass sie wieder zu den Merkmalsbeziehungen konsistent sind. Dabei werden die Ursprungssätze gelöscht und
auf die korrekten Merkmalskombinationen umgebucht.
In der Merkmalsverwendung können Sie festlegen, für welche Merkmale die Werte berichtigt werden sollen.
Sinnvoll ist dies nur für solche Merkmale, die entsprechend den Merkmalsbeziehungen abgeleitet werden
können.
 Hinweis
Beachten Sie folgende Bedingung: Eine Planungsfunktion diesen Typs kann nur auf einer
Aggregationsebene angelegt werden, die direkt auf einem planungsrelevanten InfoProvider als Datenbasis
angelegt ist (sog. einfache Aggregationsebene, siehe Aggregationsebene [Seite 23]). Die
Aggregationsebene muss sämtliche in Aggregationsebenen gültigen InfoObjekte des InfoProviders
enthalten.
 Hinweis
Da es im normalen Betrieb eines Direct Update DataStore-Objektes nicht möglich ist,

Merkmalskombinationen, also Sätze, komplett zu löschen, setzt die Planungsfunktion lediglich alle
Kennzahlen auf Null zurück. Ebenso verhält es sich bei einem lokalen Provider im BW Workspace.
Planungskonzepte
1.6.2.14.1 DSO-Daten auf der Basis von
Merkmalsbeziehungen umbuchen
Verwendung
Mit dem Funktionstyp DSO-Daten auf der Basis von Merkmalsbeziehungen umbuchen können Sie
Bewegungsdaten so umbuchen, dass sie wieder zu den Merkmalsbeziehungen konsistent sind. Im Unterschied
zum Funktionstyp Umbuchen nach Merkmalsbeziehungen werden dabei allerdings sämtliche Quelldaten aus
einem Direct Update DataStore-Objekt gelöscht und auf die korrekten Merkmalskombinationen umgebucht.
Im Falle eines DataMart DataStore-Objektes werden die Quelldaten storniert.
Umbuchen nach Merkmalsbeziehungen [Seite 92]
1.6.2.15 Umwertung
Verwendung
Mit dem Funktionstyp Umwertung können Sie Kennzahlen um einen Prozentsatz erhöhen oder verringern.
Dabei werden keine Merkmalswerte verändert. In der Merkmalsverwendung können Sie daher Merkmale nur
als Bedingungsmerkmale auswählen.
Sie können wählen, ob Sie einen gemeinsamen Prozentsatz für alle Kennzahlen eingeben oder beliebige
Kennzahlen mit individuellen Prozentsätzen umwerten möchten.
In beiden Fällen können Sie entweder direkt den Prozentsatz eingeben oder Variablen verwenden. Der
Prozentsatz wird als Delta interpretiert; das System erwartet nicht die Eingabe eines Prozentzeichens.
 Beispiel
Wenn Sie 15,4 eingeben, führt das System die folgende Berechnung aus:
neuer Wert = alter Wert + 15,4% * alter Wert.
Planungskonzepte
1.6.2.16 Verteilung nach Referenzdaten
Verwendung
Mit dem Funktionstyp Verteilung nach Referenzdaten können Sie Merkmalskombinationen, auf die verteilt wird,
entsprechend den Referenzdaten erzeugen. Dabei werden die Kennzahlwerte auch prozentual entsprechend
den Referenzdaten verteilt.
Über die Tabelle zur Kennzahlauswahl können Sie festlegen, welche Kennzahlen verteilt werden sollen.
Zur Auswahl der Referenzdaten stellt das System zwei Parameter zur Verfügung:
Referenzkennzahl (optional) Sie legen die Kennzahl fest, die in den Referenzdaten ver
wendet werden soll, um die Verteilungsschlüssel zu berech
nen.
● Wenn eine solche Kennzahl ausgewählt wird, verteilt das

System alle zu verteilenden Kennzahlen entsprechend
diesem Schlüssel, also entsprechend dieser Referenz
kennzahl.
● Wenn keine Referenzkennzahl ausgewählt wird, berech
net das System für jede zu verteilende Kennzahl einzeln
die Schlüssel. Dabei wird in den Referenzdaten dieselbe
Kennzahl verwendet, die auch verteilt wird.
Referenzwerte auf beliebigen Blockmerkmalen Sie legen für ein oder mehrere Blockmerkmale einen Refe
renzwert fest. Das System überschreibt dann beim Lesen
der Referenzdaten für jeden Block den Merkmalswert des
Blockes in diesem Merkmal durch diesen Referenzwert.
 Beispiel
Ein InfoProvider stellt Daten zu den Jahren 2005 und
2006 zur Verfügung. Sie möchten Bewegungsdaten zu
dem Jahr 2006 verändern. Daher werden die Daten des
Jahres 2006 in dem der Planungsfunktion übergebenen
Filter ausgewählt. Alle Blöcke haben als Jahr daher
2006. Durch die Angabe des Referenzwertes 2005 kön
nen Sie bewirken, dass die Schlüssel jedoch entspre
chend den Daten von 2005 berechnet werden.
Den Verteilungsvorgang können Sie auf verschiedene Weise steuern:
● Verteilung über eine Top-Down-Variante

○ Alles verteilen: Es wird über den gesamten Block aufsummiert.
○ Nur nicht zugeordnet verteilen: Es wird lediglich der Wert verteilt, der im aktuellen Block bei allen zu
verändernden Merkmalen den Merkmalswert nicht zugeordnet [#] hat.
● Verteilung über manuell erstellte Einträge in der Tabelle Von- und Nach-Werte für den Verteilungsvorgang
Planungskonzepte
Sie können einen oder mehrere Verteilungsvorgänge anlegen, indem Sie manuell die
Merkmalseinschränkungen auf den zu verändernden Merkmalen eintragen.
Das System summiert dabei die Werte der Kennzahlen auf der Von-Seite stets über alle Sätze des Blockes,
die der Merkmalseinschränkung entsprechen, und verteilt diese Summe dann auf die Nach-Werte.
Das System verteilt genau auf diejenigen Merkmalskombinationen, die in den Referenzdaten vorhanden sind
und den Merkmalseinschränkungen bei den Nach-Werten entsprechen.
Die prozentuale Verteilung entspricht der prozentualen Verteilung in den Referenzdaten.
Bei der Top-Down-Verteilung wird hier auf alle Merkmalskombinationen verteilt, die in den Referenzdaten
vorhanden sind. Dabei wird derjenige Datensatz ausgenommen, der auf Merkmalswerten der zu verändernden
Felder nicht zugeordnet [#] hat.
Wenn es für einen Teilvorgang keine Referenzdaten gibt, werden die Kennzahlwerte dieses Teilvorgangs nicht
verteilt; das System gibt eine Warnung aus.
 Hinweis
Die Schrittfolge, mit der das System die Verteilungsfunktion ausführt, entspricht der beim Ausführen der
Funktion Verteilung nach Schlüsseln. Es gelten dieselbnen Regeln. Weitere Informationen finden Sie unter
Verteilung nach Schlüsseln [Seite 95].
1.6.2.17 Verteilung nach Schlüsseln
Verwendung
Mit dem Funktionstyp Verteilung nach Schlüsseln können Sie die Merkmalskombinationen, auf die verteilt wird,
entsprechend den Stammdaten und Merkmalsbeziehungen erzeugen. Dabei werden die Kennzahlwerte
entsprechend den ausdrücklich anzugebenden Verteilungsschlüsseln verteilt. Hierbei handelt es sich um
Verteilungsfaktoren, die die Gewichtung der Anteile beim Verteilen bestimmen.
 Hinweis
Eine Einführung in die Funktionsweise einer Planungsfunktion vom Typ Verteilen nach Schlüsseln erhalten
Sie unter Ablauf einer Planungsfunktion: Verteilung nach Schlüsseln [Seite 38].
Über die Tabelle zur Kennzahlauswahl können Sie festlegen, welche Kennzahlen verteilt werden sollen.
Den Verteilungsvorgang können Sie auf verschiedene Weise steuern:
● Verteilung über eine Top-Down-Variante

○ Alles verteilen: Es wird über den gesamten Block aufsummiert.
○ Nur nicht zugeordnet verteilen: Es wird lediglich der Wert verteilt, der im aktuellen Block bei allen zu
verändernden Merkmalen den Merkmalswert nicht zugeordnet [#] hat.
● Verteilung über manuell erstellte Einträge in der Tabelle Von- und Nach-Werte für den Verteilungsvorgang
Sie können einen oder mehrere Verteilungsvorgänge anlegen, indem Sie manuell die
Merkmalseinschränkungen auf den zu verändernden Merkmalen eintragen.
Das System summiert dabei die Werte der Kennzahlen auf der Von-Seite stets über alle Sätze des Blockes,
die der Merkmalseinschränkung entsprechen, und verteilt diese Summe dann auf die Nach-Werte.
Planungskonzepte
Über die Tabelle Von- und Nach-Werte für den Verteilungsvorgang können Sie zu den Nach-Werten entweder in
der Spalte Faktor einen bestimmten Wert eingeben oder über die Wertehilfe eine Formelvariable auswählen.
Das System zeigt diese in der Spalte Faktor Variable Text an.
Wenn die Merkmalseinschränkung eines Nach-Wertes kein Einzelwert ist, gilt dieser Schlüssel für jede
Merkmalskombination, die der Merkmalseinschränkung entspricht.
Die Schlüssel werden bei der Verarbeitung normalisiert, das heißt entsprechend ihrer Größenverteilung in
Prozentsätze umgerechnet: Das System addiert die Verteilungsfaktoren, die den einzelnen Merkmalswerten
zugeordnet sind, zunächst zu einer Summe und setzt diese dann relativ zueinander ins Verhältnis. Hierbei
ergeben sich Prozentwerte, die sich immer zu 100 % summieren.
Für alle zu verteilenden Kennzahlen gelten pro Planungsfunktion die gleichen Schlüssel.
Auf der Nach-Seite werden für die angegebenen Merkmalseinschränkungen Kombinationen erzeugt. Dies
geschieht in Konsistenz mit den Stammdaten und den auf den InfoProvidern definierten
Merkmalsbeziehungen. Wenn das System dabei für einen Block und einen Teilvorgang kein Ziel findet, bricht
die Funktion mit einer Fehlermeldung ab.
 Hinweis
Das System führt zur Ausführung einer Planungsfunktion vom Typ Verteilung folgende Schritte durch:
1. Die Summe des gesamten zu verteilenden Betrags wird ermittelt.

2. Bei den von den Von-Werten betroffenen Datensätzen werden die Kennzahlwerte gelöscht.
3. Entsprechend den Verteilungsschlüsseln werden die Summen auf die Kennzahlwerte der durch die
Nach-Werte ausgewählten Datensätze aufaddiert.
● Sowohl die Von- als auch die Nach-Werte werden verändert und müssen daher im Filter enthalten sein, der
Wenn der Von-Wert so angelegt ist, dass er Datensätze auswählen könnte, die nicht im Filter liegen, gibt
das System keine Fehlermeldung aus. Die Datensätze gehen nicht in die Verteilung ein.
Wenn der Nach-Wert so angelegt ist, dass er Datensätze auswählen könnte, die nicht im Filter liegen, bricht
das System die gesamte Planungsfunktion mit einer Fehlermeldung ab.
Wenn ein Ziel in mehreren Teilvorgängen genannt wird, enthält es nach dem Ausführen der Funktion die
entsprechende Summe.
● Rundungsdifferenzen werden gleichmäßig auf diejenigen Zieldatensätze verteilt, die bereits ungleich Null
sind.
1.6.2.18 Währungsumrechnung
Verwendung
Mit dem Funktionstyp Währungsumrechnung können Sie Währungen aus Kennzahlen in andere Kennzahlen
umrechnen.
In der Tabelle Kennzahlen und Währungsumrechnungsarten können Sie mehrere Umrechnungen angeben. Für
jede Umrechnung müssen Sie eine Währungsumrechnungsart sowie Quell- und Zielkennzahl auswählen. Der
Wert in der Zielkennzahl wird überschrieben. Dies gilt auch dann, wenn die Quellkennzahl leer ist. Der Wert der
Planungskonzepte
Quellkennzahl bleibt bei der Währungsumrechnung erhalten. Dadurch kann die Funktion mehrmals
hintereinander ausgeführt werden, ohne dass sich die Ergebnisse verändern. Damit dies auch gewährleistet ist,
wenn die Quellkennzahl und die Zielkennzahl identisch sind und die Quelleinheit aus dem Datensatz verwendet
wird, gibt es hierfür eine spezielle Logik: Falls es bereits einen Wert in der Zieleinheit gibt, wird dieser dann
vernachlässigt, wenn Werte in der Quelleinheit vorhanden sind, die nicht die Zieleinheit besitzen. Andernfalls
wird der Wert in der Zieleinheit übernommen.
 Beispiel
Die Währungsumrechnung rechnet die Kennzahl Betrag mit der Quellwährung im Datensatz in die fixe
Zielwährung EURO um. Als Zeitbezug wurde der Stichtag 01.01.2001 gewählt. Es sind zwei Datensätze zu
unterschiedlichen Gesellschaften vorhanden. Die Gesellschaft 4711 ist in CHF geplant. Die Gesellschaft
0815 ist bereits in EUR geplant.
Betrag Währung Gesellschaft
10 CHF 4711
4 EUR 0815
10 CHF 4711
6,3 EUR 4711
4 EUR 0815
Es entsteht ein neuer Datensatz.
10 CHF 4711
6 EUR 4711
9 EUR 0815
10 CHF 4711
6,3 EUR 4711
9 EUR 0815
Der Wert zur Gesellschaft 4711 wird durch die Währungsumrechnung überschrieben.
Im Rahmen der Planungsfunktionen werden nicht alle Zeitbezüge der Währungsumrechnungsarten

unterstützt. Nicht unterstützt sind Auswahl bei Umrechnung und Querystichtag. Anstelle dieser Zeitbezüge
Planungskonzepte
können Sie Variablen verwenden. Für den Querystichtag können Sie die Variable 0PLANDAT benutzen. Wenn
Sie das Datum bei der Ausführung der Planungsfunktion eingeben möchten, verwenden Sie eine
eingabebereite Variable.
Zu verändernde Merkmale können diejenigen Merkmale sein, in denen die Währungsschlüssel stehen.
Standardmäßig sind alle Merkmale markiert, die Währungsschlüssel enthalten. Sie können diese Einstellung im
Regelfall übernehmen.
 Hinweis
Beachten Sie die folgenden Hinweise zur Modellierung:
Falls Sie Plandaten in unterschiedlichen Währungen erfassen möchten, bietet es sich an, für jeden
Verwendungszweck Kennzahlen mit eigenen Feldern für Währungsschlüssel zu verwenden. Beispiele für
solche Verwendungszwecke sind Erfassung der Originalbeträge in Gesellschaftswährung und Konsolidierung
der Beträge in Konzernwährung. Über Merkmalsbeziehungen können Sie sicherstellen, dass zu einer
Gesellschaft nur ein passender Währungsschlüssel eingetragen werden kann. Die Aggregationsebenen
können auf einfache Weise so modelliert werden, dass für jeden Verwendungszweck mit unterschiedlichen
Datentöpfen gearbeitet wird.
Es werden immer nur diejenigen Kennzahlen in die Aggregationsebene aufgenommen, die verwendet
werden. Falls Sie eine Kennzahl für unterschiedliche Verwendungszwecke verwenden, müssen Sie die
Daten über Selektionen in Filtern abgrenzen.
1.6.3 Standardstichtag in Planungsfunktionen
Der Standardstichtag ist ein Stichtag, der im gesamten Planungsmodell verwendet wird; er kann für jeden
Basis-InfoProvider festgelegt werden.
Verwendung
Folgende Möglichkeiten der Festlegung eines Stichtages stehen zur Wahl:
● Unspezifiziert (Standardwert ist das Systemdatum, falls alle beteiligten InfoProvider den Stichtag =
unspezifiziert haben)
● Festes Datum
● Aus Variable
Alle Objekte, die vom Stichtag abhängig sind, wie z.B. der Filter oder Hierarchien, die im Filter verwendet
werden oder in den Von- und Nach-Werten der Kopier- oder Verteilungsfunktionen, können auf den
Standardstichtag gesetzt werden.
Wenn eine Planungsfunktion ausgeführt wird, berechnet das System den Standardstichtag wie folgt.
● Wenn die Aggregationsebene direkt auf einem planungsrelevanten InfoProvider angelegt worden ist, ist der
Standardstichtag gleich demjenigen Stichtag, der für diesen InfoProvider gesetzt ist.
Planungskonzepte
● Wenn die Aggregationsebene auf einem CompositeProvider angelegt worden ist, werden alle beteiligten
planungsrelevanten InfoProvider unterhalb des CompositeProviders geprüft. Falls diese alle die Einstellung
unspezifiziert haben, ist der Standardstichtag das aktuelle Systemdatum. Wenn einer der
planungsrelevanten InfoProvider eine andere Einstellung bei seinem Stichtag hat, gewinnt der erste, der
einen bestimmten Wert zurückgibt. Variablen werden bei der Rückgabe ausgewertet.
Alle zeitabhängigen Objekte bieten aber weiterhin auch die Möglichkeit, in ihrer konkreten Anwendung einen
eigenen Stichtag zu verwenden.
 Beispiel
Dies kann z.B. in folgendem Fall sinnvoll sein: Sie möchten eine bestimmte Hierarchie verwenden, die mit
einem anderen Stichtag gelesen werden soll, als die Stammdatenattribute.

Informationen über die Einstellung zum Stichtag der Planung finden Sie in diesem Abschnitt der
Dokumentation zu den BW-Modellierungswerkzeugen.
1.7 Planungssequenz
Planungssequenzen dienen zur Gruppierung von Planungsfunktionen. Sie ermöglichen das Abspeichern von
Gruppen von Planungsfunktionen in einer sortierten Reihenfolge sowie das sortierte Ausführen der gesamten
Gruppe.
Funktionsumfang
Eine Planungssequenz kann aus einem oder mehreren Schritten bestehen. Es gibt folgende Typen von
Schritten:
Typ Beschreibung
Planungsfunktion Ausgehend von einer Aggregationsebene sichert das System

eine Planungsfunktion und einen Filter, mit dem die Pla
nungsfunktion ausgeführt wird.
Planungskonzepte
Typ Beschreibung
Eingabemaske Eingabemasken können Sie insbesondere zum Testen von

Planungsfunktionen in die Sequenz einbetten. Eingabemas
ken werden durch eine Aggregationsebene und einen Filter
definiert.
Wenn eine Planungssequenz als Ganzes ausgeführt wird,

werden die eingebetteten Eingabemasken nicht berücksich
tigt.
Aktivitäten
Aktivität
Testen Über Ausführen können Sie Planungssequenzen als Ganzes

ausführen oder Schritt für Schritt testen.
Ausführen innerhalb einer Prozesskette Sie können eine Planungssequenz als Prozesstyp
Planungssequenz ausführen in eine Prozesskette einbetten.
Dabei kann die Planungssequenz mit einer abgespeicherten
Variante für Variablenwerte in Verbindung gebracht werden.
Planungssequenz in Prozesskette einplanen [Seite 100]

Planungssequenz für Bottom-Up-Planung [Seite 107]
Planungssequenz anlegen [Seite 188]
1.7.1 Planungssequenz in Prozesskette einplanen
Verwendung
Über die Integration in Prozessketten können Sie Planungssequenzen im Hintergrund ausführen.
Sie können eine Planungssequenz in eine Prozesskette aufnehmen, indem Sie in eine bestehende Prozesskette
einen Prozess des Prozesstyps Planungssequenz ausführen aufnehmen. In der Detailpflege des Prozesses
wählen Sie die gewünschte Planungssequenz aus sowie ggf. eine passende Variablenvariante.
Bei der Ausführung im Hintergrund können Sie einstellen, ob und wie die Planungssequenz in kleinere Pakete
aufgeteilt werden soll. Diese Pakete können auch parallel in einzelnen Teiljobs auf mehreren Arbeitsprozessen
ausgeführt werden.
Planungskonzepte
Die parallele Ausführung kann über die Hintergrundverwaltung (Transaktionscode RSBATCH) überwacht und
analysiert werden.
Voraussetzungen
● Um eine Planungssequenz innerhalb einer Prozesskette einplanen zu können, müssen Sie die
Planungssequenz zunächst in den BW-Modellierungswerkzeugen anlegen.
● Sie haben in der Prozesskettenpflege (Transaktionscode RSPC) die gewünschte Prozesskette angelegt und
ggf. das Verhalten der Prozesskette bei der Ausführung festgelegt. Weitere Informationen finden Sie unter
sowie
.
● Wenn Ihre Planungssequenz Variablen enthält, die nur über Benutzervorgaben gefüllt werden können, oder
wenn Sie Variablen über Benutzervorgaben überschreiben möchten, können Sie in den BW-
Modellierungswerkzeugen eine Variablenvariante hinterlegen. In der Pflege des Prozesses, mit dem Sie die
Planungssequenz einplanen, können Sie auf diese Variablenvariante verweisen.
 Hinweis
Sie können Variablenvarianten entweder lokal für einen Benutzer oder als globale Variablenvarianten
abspeichern. Wenn Sie eine lokale Variablenvariante verwenden möchten, müssen Sie den Benutzer,
für den die Variablenvariante erstellt wurde, auch bei der Definition des Prozesses und als Benutzer für
die Hintergrundausführung verwenden. Weitere Informationen finden Sie unter Variable [Seite 30] und
(Ausführungsbenutzer).
 Hinweis
Beachten Sie, dass Änderungen, die kurz vor der Ausführung auf einem Applikationsserver gemacht
werden, nicht unbedingt sofort auf allen Applikationsservern aktiv sind. Dies ist abhängig von den
Einstellungen zur Datenbankpufferung in Ihrem System und gilt sowohl für viele SAP BW∕4HANA-
Objekte, als auch für Änderungen in verwendeten Kunden-Exits. Im Produktivsystem ist also dringend
zu beachten, dass zwischen der letzten Änderung irgendwelcher Objekte und dem Einplanen der
Prozesskette mindestens die Zeit vergangen ist, die Sie für die Aktualisierung der Datenbankpufferung
gewählt haben.
Vorgehensweise
1. Legen Sie in der Prozesskettenpflege einen Anwendungsprozess vom Typ Planungssequenz ausführen an.
 Hinweis
Beachten Sie, dass manche SAP BW∕4HANA-Objekte bei Lesezugriffen den Tabellenpuffer verwenden.
Wenn Sie also Planungssequenzen auf mehreren Servern verteilt einplanen wollen, sollten Sie darauf
achten, dass die Standardzeit, die Sie für den Tabellenpuffer eingestellt haben, zwischen dem
eingeplanten Start und ihrer letzten Änderung verstrichen ist (Auslieferungsstandardzeit ist 120s).
Planungskonzepte
2. Wählen Sie die gewünschte Planungssequenz und ggf. eine Variablenvariante aus.
3. Wählen Sie Übernehmen.
4. Legen Sie im Bildbereich Paketierung an oder ausschalten fest, ob die Planungssequenz als Ganzes
ausgeführt oder ob sie in Paketen verarbeitet werden soll.
Auswahlmöglichkeit Beschreibung
Ohne Paketierung verarbeiten Die gesamte Planungssequenz wird als Ganzes ausge
führt. Nur wenn alle enthaltenen Funktionen ohne Fehler
ausgeführt werden, sichert das System abschließend alle
Daten auf der Datenbank.
Bei dieser Option sind keine weiteren Einstellungen zu

treffen.
In Paketen verarbeiten Die Planungssequenz wird Schritt für Schritt ausgeführt.

Das System schreibt nach jedem Schritt die veränderten
Daten auf die Datenbank und löscht sie aus dem Puffer.
Sie können für jeden Schritt einstellen, ob und wie pake

tiert werden soll. Wenn ein Schritt paketiert wird, schreibt
das System jedes einzelne Paket, dass für sich fehlerfrei
verarbeitet wurde, auf die Datenbank.
Wenn Sie die Planungssequenz in Paketen verarbeiten möchten, liest das System die Schritte der
Planungssequenz von der Datenbank und füllt eine Tabelle. Dabei werden nur diejenigen Schritte der
Planungssequenz angezeigt, die eine Planungsfunktion ausführen.
 Hinweis
Die Schrittnummern werden dabei von der Datenbank übernommen. Da die Schritte für
Eingabemasken fehlen ist die Nummerierung nicht durchgängig.
5. Wenn Sie die Option In Paketen verarbeiten gewählt haben, können Sie für jeden Schritt wählen, welche der
folgenden Paketierungsarten angewendet werden soll.
Keine Paketierung Für einen solchen Schritt wird genau ein Teiljob über die
Hintergrundverwaltung eingeplant. Dieser führt die Pla
nungsfunktion für den gesamten Filter des Schrittes aus.
Planungskonzepte
Automatische Paketierung Das Merkmal, über das der Schritt paketiert wird, wird
zum Ausführungszeitpunkt automatisch bestimmt. Sie
können in der letzten Spalte der Tabelle einstellen, in wie
viele Pakete das System den Filter zerlegen soll.
Außerdem können Sie einstellen, ob die Werte über die

Stammdatentabelle oder über die Dimensionstabelle er
mittelt werden sollen. (Weitere Informationen finden Sie
unten im Abschnitt Werte für ein Merkmal ermitteln.)
Konfigurierte Paketierung Das Merkmal, über das der Schritt paketiert wird, muss
ausgewählt werden. Es stehen Ihnen zwei Hilfen zur Aus
wahl des Merkmals zur Verfügung.
1. Zum InfoObject-Feld steht Ihnen eine Wertehilfe zur Ver

fügung, die es Ihnen erlaubt, für alle Merkmale, die für die
Paketierung in Frage kommen, die Werteanzahlen schät
zen zu lassen.
2. Sie können einige Schritte auswählen und sich für diese

ein Merkmal vorschlagen lassen. Dabei können Sie zuvor
in der letzten Spalte vorgeben, wie viele Pakete gebildet
werden sollen.
Außerdem können Sie einstellen, ob die Werte über die

Stammdatentabelle oder über die Dimensionstabelle er
mittelt werden sollen. (Weitere Informationen finden Sie
unten im Abschnitt Werte für ein Merkmal ermitteln.)
Für das gewählte InfoObject können Sie festlegen, wie

viele Einzelwerte des Merkmals in ein Paket aufgenommen
werden sollen.
Das System berechnet die Paketanzahl aus der Anzahl al

ler Werte dividiert durch die Wertanzahl pro Paket und
rundet dies nach oben, entsprechend der Formel: Pake
tanzahl = ceil (Anzahl aller Werte / Wertanzahl pro Paket).
Werte für ein Merkmal ermitteln
Zur Ermittlung der Werte, die für ein Merkmal relevant sind, gibt es zwei Ansätze. In beiden Fällen wird die
Merkmalseinschränkung aus dem Filter bezüglich des zu untersuchenden Merkmals verwendet.
Mit dieser Merkmalseinschränkung wird dann entweder die Stammdatentabelle oder die Dimensionstabelle
gelesen. Die Stammdatentabelle enthält alle Werte, die es für dieses Merkmal gibt. Die Dimensionstabelle
enthält alle Werte, die in den beteiligten InfoProvidern bereits gespeichert sind.
 Hinweis
In beiden Fällen können sich die Werte in den Tabellen durch den Lauf einer Planungsfunktion ändern:
Bei allen Merkmalen, die bisher nicht im InfoProvider enthalten waren, können Werte in Dimensionstabellen
geschrieben werden.
Planungskonzepte
Bei Merkmalen, die keine Stammdatentabelle haben, greift das System bei der Leseart Stammdaten auf
die SID-Tabelle zurück. In diesem Fall können durch den Lauf einer Planungsfunktion ebenfalls neue Werte
entstehen.
Funktionsweise der Privilegsperre
Um zu vermeiden, dass Teile einer Planungssequenz nicht ausgeführt werden können, weil andere Benutzer
Daten sperren, sperrt das System die Daten aller Schritte vorab.Wenn die Planungssequenz in Paketen
verarbeitet wird, werden Privilegsperren benutzt. Hier gibt der Master-Prozess eine Privilegsperren-ID an die
Teiljobs mit.
Zu Beginn der Ausführung sperrt der Master-Prozess die Vereinigung aller Filter beim Sperrserver. Dieser setzt
eine Privilegsperre, gibt die normalen Sperren wieder frei und gibt eine ID für die Privilegsperre zurück. Ab jetzt
dürfen nur noch solche Arbeitsprozesse die Daten innerhalb der Filter verändern, die sich über diese
Privilegsperren-ID ausweisen können. Die Teiljobs weisen sich mit der Privilegsperren-ID aus, sichern die Daten
dann auch durch eine normale Sperre. Wenn die Planungssequenz vollständig abgearbeitet ist, gibt der Master-
Prozess die Privilegsperre wieder frei.
Sie können die Privilegsperren in der Sperrverwaltung (Transaktion RSPLSE) überwachen. (Weitere
Informationen finden Sie unter Sperrkonzept und Sperrverwaltung [Seite 166].)
 Hinweis
In seltenen Fällen (z.B. wenn der Administrator den Master-Prozess absichtlich abbricht) kann es
vorkommen, dass die Privilegsperre nicht vom System freigegeben wird. Sie können die Privilegsperre dann
manuell in der Sperrverwaltung löschen. Dies setzt allerdings voraus, dass Sie die Berechtigung zum
Ausführen der Planungssequenz haben. Wenn Teiljobs noch offen sind, kann das System diese dann nicht
mehr erfolgreich ausführen.
Bestimmung der Merkmale, die für die Paketierung in Frage kommen
Nicht alle Merkmale einer Aggregationsebene, auf der eine Planungsfunktion angelegt ist, kommen für die
Paketierung in Frage.
● Im Hinblick auf die Funktion kommen nur diejenigen Merkmale in Frage, die nicht zu verändernde
Merkmale sind.
Wie oben im Abschnitt über die Funktionsweise der Privilegsperre beschrieben, erfragen die Teiljobs für
ihre Filterpakete echte Sperren bei der Sperrverwaltung. Für jeden planungsrelevanten InfoProvider
können Sie in der Sperrverwaltung konfigurieren, welche seiner Merkmale für Sperren relevant sein sollen.
Um zu vermeiden, dass sich die Teiljobs gegenseitig sperren, weil ihre Filterpakete aus Sicht der
Sperrverwaltung nicht zu separieren sind, können nur ausgesuchte Merkmale zur Paketierung verwendet
werden.
● Im Hinblick auf die Sperrverwaltung kommen ebenfalls nur bestimmte Merkmale zur Paketierung in Frage.
Wie diese bestimmt werden, sehen Sie in der folgenden Tabelle:
Bestimmung der zur Paketierung erlaubten Merkmale

Typ der Aggregationsebene auf dieser Aggregationsebene
Einfache Aggregationsebene [Seite 26] (ist direkt auf ei Erlaubt sind genau die für Sperren relevanten Merkmale
nem planungsrelevanten InfoProvider angelegt) des planungsrelevanten InfoProviders.
Planungskonzepte
Bestimmung der zur Paketierung erlaubten Merkmale
Typ der Aggregationsebene auf dieser Aggregationsebene
Komplexe Aggregationsebene [Seite 27] (ist auf einem Ein Merkmal ist genau dann erlaubt, wenn die folgende
CompositeProvider angelegt) Regel für alle beteiligten planungsrelevanten InfoProvider
erfüllt ist: Wenn das Merkmal von einem planungsrelevan
ten InfoProvider versorgt wird, muss es in diesem relevant
für Sperren sein.
Die folgende Grafik veranschaulicht den Fall einer komplexen Aggregationsebene:
Die Planungsfunktion F1 ist auf der Aggregationsebene A1 angelegt.

Die Aggregationsebene A1 ist auf dem CompositeProvider CP1 angelegt.
Dieser wird aus den InfoProvidern IP1, D1 und D2 versorgt.
Der InfoProvider DIP1 ist kein planungsrelevanter Basis-InfoProvider. Aus ihm werden die Merkmale A, B, C,
D und E im CompositeProvider CP1 versorgt. Auf ihm werden keine Sperren verwaltet. Er ist daher bei den
weiteren Betrachtungen nicht relevant.
Der InfoProvider D1 ist ein DataMart DataStore-Objekt. Aus ihm werden die Merkmale A, B, C, D und F im
CompositeProvider CP1 versorgt. In der Sperrverwaltung sind davon die Merkmale A, B, D und F als für
Sperren relevant eingetragen.
Der InfoProvider D2 ist ein DataMart DataStore-Objekt. Aus ihm werden die Merkmale A, D, E und F im
CompositeProvider CP1 versorgt. In der Sperrverwaltung sind davon die Merkmale A, E und F als für
Sperren relevant eingetragen.
Nach der oben genannte Regel ergeben sich aus den Merkmalen des CompositeProviders die Merkmale A,
B, E und F als zur Paketierung erlaubt:
○ A und F werden aus D1 und D2 versorgt und sind in beiden für Sperren relevant. A und F sind daher
erlaubt.
Planungskonzepte
○ B wird nur aus D1 versorgt und ist dort für Sperren relevant. B ist daher erlaubt.
○ C wird nur aus D1 versorgt und ist dort nicht für Sperren relevant. C ist daher nicht erlaubt.
○ D wird aus D1 und D2 versorgt, ist aber in D2 nicht für Sperren relevant. D ist daher nicht erlaubt.
○ E wird nur aus D2 versorgt und ist dort für Sperren relevant. E ist daher erlaubt.
Da die Aggregationsebene F nicht enthält, bleiben die Merkmale A, B und E übrig.
In der Planungsfunktion wird E als zu veränderndes Merkmal verwendet. Also kommen nur A und B zur
Paketierung in Frage.
Automatische Auswahl eines Merkmals
Wenn die automatische Auswahl eines Merkmals angefordert wird, müssen auch die gewünschte Anzahl der
Pakete und die gewünschte Art der Ermittlung der Werte definiert sein.
Das System bestimmt dann die zur Paketierung erlaubten Merkmale. Für diese wird der Reihe nach ermittelt,
wie viele Merkmalswerte in der jeweiligen Merkmalseinschränkung enthalten sind. Sobald ein Merkmal
gefunden wird, für das das System mehr Merkmalswerte gefunden hat als Pakete angefordert sind, wird dies
zur Paketierung vorgeschlagen bzw. verwendet.
Zerlegung des Filters in Pakete
Wenn für einen Schritt ein Filter in Pakete zerlegt werden soll, wird zuvor definiert, welches Merkmal zur
Paketierung verwendet wird, welche Art der Ermittlung der Werte verwendet wird, und es wird entweder die
Paketanzahl oder die Werteanzahl pro Paket festgelegt.
Die Werte werden nun zufällig (aber reproduzierbar) auf die Menge der Pakete verteilt, so dass jedes Paket
mindestens einen Wert enthält aber nicht mehr als die Werteanzahl pro Paket.
Einstellungen zur physischen Parallelität
Über Parallelverarbeitung in der Pflege des Prozesses vom Typ Planungssequenz ausführen haben Sie die
Möglichkeit, für diesen Prozess die Standardwerte für den Prozesstyp PLSEQ zu überschreiben.
Die Standardwerte für einen Prozesstyp können Sie in der Hintergrundverwaltung hinterlegen.
Sie können über diese Einstellungen festlegen,
● in wie vielen parallelen Arbeitsprozessen die Teiljobs ausgeführt werden sollen

● auf welchen Servern diese Arbeitsprozesse ausgeführt werden sollen
● mit welcher Priorität die Teiljobs ausgeführt werden sollen
Abarbeitung der Planungssequenz Schritt für Schritt
Wenn Sie die Option In Paketen verarbeiten gewählt haben, wird die Planungssequenz Schritt für Schritt
abgearbeitet.
Jeder Schritt wird in die gewünschte Anzahl von Teiljobs zerlegt; dann werden alle Teiljobs des Schrittes über
die Hintergrundverwaltung eingeplant. Der Master-Prozess überprüft, ob alle Teiljobs des letzten Schrittes
ausgeführt wurden. Sobald dies geschehen ist, wird, falls alle Teiljobs erfolgreich waren, mit dem nächsten
Schritt fortgefahren. Wenn einer der Teiljobs mit einem Fehler abgebrochen ist, wird die Planungssequenz nicht
weiter ausgeführt. In diesem Fall plant der Master-Prozess noch einen Abschluss-Teiljob ein, der dazu dient, der
Hintergrundverwaltung mitzuteilen, dass die reservierten physischen Arbeitsprozesse freigegeben werden
können. Der Master-Prozess gibt abschließend auch die Privilegsperre frei.
Planungskonzepte

Planungssequenz für Bottom-Up-Planung [Seite 107]
1.7.2 Planungssequenz für Bottom-Up-Planung
Verwendung
Definition der Planungssequenz
Als Beispiel betrachten wir eine Planungssequenz, die einen Bottom-Up-Planungsprozess vorbereiten soll.
Diese besteht aus drei Schritten.
1. Für alle vorhandenen Produkte und Regionen wird auf der Grundlage der Ist-Daten für Verkaufsstückzahlen
eine lineare Regression durchgeführt; daraus ergibt sich die Prognose der Daten für die Monate des
nächsten Jahres. Diese Version der Daten wird unter der Version PLAN_LIN aufbewahrt.
2. Für zwei neue Produkte werden die Verkaufszahlen von ähnlichen Produkten abgeleitet. Dies geschieht
durch eine Kopierfunktion.
3. In einer Bottom-Up-Planung sollen die für die einzelnen Regionen zuständigen Planer die prognostizierten
Zahlen nach ihren Einschätzungen anpassen. Da man aber zum Vergleich die prognostizierten Daten
erhalten möchte, wird für diese Planungsrunde eine weitere Version der Daten zur Verfügung gestellt. Auch
dies geschieht über eine Kopierfunktion.
Alle drei Funktionen arbeiten in diesem Beispiel auf der gleichen Aggregationsebene:
● Merkmale: Version, Kalendermonat, Region und Produkt.

● Kennzahl: Anzahl verkaufte Stücke.
Alle Merkmale sind in allen beteiligten Basis-InfoProvidern relevant für Sperren und kommen daher als
Paketierungsmerkmal in Frage.
Übersicht der in der Planungssequenz enthaltenen Funktionen
Schritt 1. 2. 3.
Funktionstyp Prognose Kopieren Kopieren
Kommentar Schreibt die Daten für Prog Kopiert die Daten in Version Kopiert die prognostizierten
nosezeitraum auf Version PLAN_LIN auf zwei neue Pro Daten aus Version PLAN_LIN
PLAN_LIN. Die Referenzda dukte an Hand von ähnlichen, auf eine weitere Arbeitsver
ten werden aus Version AC bereits verkauften Produk sion PLAN_BOTTOM für die
TUALS gelesen. ten. BOTTOM-UP-Planung.
Filter Version = PLAN_LIN, Monat Version = PLAN_LIN Version = PLAN_BOTTOM

= Jan 2017-Dez 2017
Planungskonzepte
Schritt 1. 2. 3.
Zu verändernde Merkmale Monat Produkt Version

der Funktion
Parameter der Funktion Vergangenheit: Jan 2015 - Vorgang 1: Vorgang 1:

Dez 2016,
Von Produkt 77 Von Version PLAN_LIN
Vergangenheitsfilter: Version
Nach Produkt 105 Nach Version PLAN_BOT
= ACTUALS,
TOM
Vorgang 2:
Prognosezeitraum: Jan 2017
- Dez 2017, Von Produkt 93
Prognoseparameter: Lineare Nach Produkt 106

Regression
Einplanen der Planungssequenz
Die Planungssequenz soll in einer Prozesskette eingeplant werden.
In der Detailpflege des Prozesses wird die Planungssequenz ausgewählt, jedoch keine Variablenvariante, da alle
enthaltenen Variablen ohne Benutzerinteraktion ersetzt werden können.
Da es sich um mittlere Datenvolumen handelt, wird die Einstellung In Paketen verarbeiten ausgewählt. Aus
Gründen der Übersichtlichkeit und Anschaulichkeit werden die Schritte in diesem Beispiel allerdings nur in
wenige Pakete aufgeteilt, für diese aber möglichst unterschiedliche Paketierungsarten gewählt.
Aufteilung der Planungssequenz in Pakete und Paketierungsarten
Schritt 1. 2. 3.
Art der Paketierung konfiguriert Keine Paketierung Automatisch
InfoObject Region
Methode für die Paketauftei Dimension Dimension

lung
Geschätzte Anzahl Werte 10
Paketgröße 4
Anzahl Pakete 3 1 3
Abarbeiten des Prozesses
Die folgende Grafik gibt einen Überblick über den Master-Prozess, der die Planungssequenz in die Prozesskette
einbindet. Er verwaltet die Ausführung der Planungssequenz, plant die Teiljobs ein, und sammelt die
Ergebnisse der Teiljobs. Dabei werden die Filter der Schritte gemäß den Einstellungen in Pakete aufgeteilt und
über die Hintergrundverwaltung in parallelen Hintergrundprozessen ausgeführt.
Planungskonzepte
Master-Prozess Schritt 1:
● Der Master sammelt alle Filter auf und setzt eine Schreibsperre beim SAP BW∕4HANA-Sperrserver. Dabei
bekommt er vom SAP BW∕4HANA-Sperrserver eine Privilegsperre. Danach wird die echte Sperre wieder
freigegeben.
● Der erste Filter wird über das vorgegebene Merkmal Region in drei Pakete mit höchstens vier Werten
aufgeteilt.
● Über die Hintergrundverwaltung werden drei Teiljobs eingeplant.
● Der Master wartet bis die Hintergrundverwaltung alle drei Teiljobs ausgeführt hat. Nur wenn alle Teiljobs
erfolgreich ausgeführt wurden, führt das System den nächsten Schritt aus.
● Für Schritt 2 der Planungssequenz ist keine Paketierung konfiguriert. Daher wird nur ein Teiljob mit dem
gesamten Filter eingeplant.
● Der Master wartet bis die Hintergrundverwaltung den Teiljob ausgeführt hat. Nur wenn dieser erfolgreich
ausgeführt wurde, führt das System den nächsten Schritt aus.
● Für Schritt 3 ist automatische Paketierung mit drei Paketen angefragt. Der Master sucht ein Merkmal, dass
mindestens drei Merkmalswerte besitzt und teilt den Filter dann entsprechend in drei Pakete auf.
● Über die Hintergrundverwaltung werden drei Teiljobs eingeplant.
Master-Prozess Ende:
● Der Gesamtstatus der Planungssequenz wird vermerkt; die Logs werden zum letzten Mal geschrieben.
● Das System hebt die Privilegsperre wieder auf.
1.8 Planungsfunktionstyp implementieren
Ein Planungsfunktionstyp ist ein parametrisierbares Verfahren, um Bewegungsdaten zu verändern. Das System
bietet Ihnen eine Reihe Standard-Planungsfunktionstypen. Um spezielle Verfahren zu realisieren und
anschließend auf Bewegungsdaten anzuwenden, können Sie kundeneigene Planungsfunktionstypen
implementieren.
Planungskonzepte
Aufbau eines Planungsfunktionstyps
Jeder Planungsfunktionstyp besteht aus folgenden Teilen:
● einem Definitionsteil (Metadaten), der in der Pflegetransaktion für Pflanungsfunktionstypen (RSPLF1)

angelegt und geändert wird,
● einer ABAP-OO-Klasse, in welcher das eigentliche Verfahren programmiert ist. Der Klassenname ist
Bestandteil des Definitionsteils.
● Falls Sie Ihre eigenen Planungsfunktionstypen auf der SAP HANA-Datenbank ausführen möchten, müssen
Sie eine SQLScript-Procedure implementieren und die nötigen SAP HANA-Objekte erzeugen.
 Nicht vergessen
Wenn Sie die kundeneigenen Planungsfunktionstypen für die SAP HANA-Datenbank implementiert haben,
empfehlen wir, sicherzustellen, dass die Business-Logik auch für die ABAP-Laufzeit implementiert ist. Dies
hat interne Gründe, ist darüber hinaus aber z.B. auch dann sinnvoll, wenn Sie zwar in Ihrem
Produktivsystem die SAP HANA-Datenbank im Einsatz haben, aber nicht in Ihrem Testsystem und dennoch
dieselben Planungsfuntkionstypen verwenden möchten.
Integration
In der Pflegetransaktion für Planungsfunktionstypen (RSPLF1) können Sie kundeneigene

Planungsfunktionstypen anzeigen, ändern, anlegen bzw. kopieren.
Planungsfunktionstypen verhalten sich in bezug auf Transport, Business Content und Aktivierung wie andere
Metadaten-Objekte des SAP BW∕4HANA-Systems. Bei Planungsfunktionstypen auf der SAP HANA-Datenbank
müssen Sie die SAP HANA-Objekte allerdings selbst transportieren.
Die aktiven Planungsfunktionstypen sind in den BW-Modellierungswerkzeugen sichtbar und können zur
Erstellung und Ausführung von Planungsfunktionen eingesetzt werden.
Vorgehensweise
1. Um in die Pflegetransaktion für Planungsfunktionstypen zu gelangen, geben Sie den Transaktionscode

RSPLAN ein.
2. Geben Sie einen technischen Namen für den Planungsfunktionstyp an.
3. Wählen Sie Anlegen. Sie gelangen auf das Bild zum Anlegen des Planungsfunktionstyps.
4. Geben Sie eine Beschreibung für den Planungsfunktionstyp an, und nehmen Sie die erforderlichen
Einstellungen auf den Registerkarten Eigenschaften und Parameter vor.
Die weitere Vorgehensweise unterscheidet sich, je nachdem, ob Sie ohne oder mit der SAP HANA-
Datenbank arbeiten möchten oder ob der Funktionstyp sowohl im ABAP-Fall als auch auf der SAP HANA-
Datenbank lauffähig sein soll.
5. Falls Sie einen kundeneigenen Planungsfunktionstyp wiederverwenden und ggf. nur geringfügig abwandeln
möchten, wählen Sie Kopieren.
Planungskonzepte
 Hinweis
Falls Sie z.B. einen kundenspezifischen Planungsfunktionstyp angelegt haben, um über eine
Planungsfunktion Daten aus einem Flatfile in die SAP BW∕4HANA-integrierte Planung zu laden, kann
ein solcher Upload-Planungsfunktionstyp viele Parameter enthalten, je nachdem, wie die Struktur des
Flatfiles aussieht. Wenn nun ein neues Flatfile mit leicht geänderter Struktur zum Upload verwendet
werden soll, wird ein neuer Planungsfunktionstyp benötigt, dessen Parameterliste der Struktur des
Flatfiles angepasst sein muss. Über Kopieren können Sie einen neuen Planungsfunktionstyp anlegen,
der die Parameter aus einem existierenden Planungsfunktionstyp übernimmt. Über Ändern können Sie
diesen dann entsprechend den Vorgaben modifizieren. Dieses Vorgehen ist oft schneller, als sämtliche
Parameter neu anzulegen.
Business-Logik für Planungsfunktionstyp in ABAP-Klasse implementieren [Seite 111]

Business-Logik für Planungsfunktionstyp auf der SAP HANA-Datenbank implementieren [Seite 115]
Parameter der Interfacemethode execute_sql_script [Seite 118]
Beispiel-Implementierung einer Interfacemethode in SQLScript [Seite 120]
1.8.1 Business-Logik für Planungsfunktionstyp in ABAP-

Klasse implementieren
Indem Sie eine ABAP-Klasse implementiern und parametrisieren, können Sie einen kundeneigenen
Planungsfunktionstyp implementieren.
Voraussetzungen
● Sie haben einen Planungsfunktionstyp angelegt.
Kontext
Sie möchten für den neuen Planungsfunktionstyp eine ABAP-Klasse implementieren und Parameter festlegen.
Planungskonzepte
Vorgehensweise
1. Sie befinden sich auf der Registerkarte Eigenschaften. Legen Sie eine ABAP-Klasse an, und implementieren
Sie das relevante Interface.
Bildbereich Beschreibung
Implementierung Geben Sie den Namen der ABAP-Klasse an, welche das
Verfahren realisiert. Die ABAP-Klasse muss hierfür eines
der beiden Interfaces implementieren:
○ IF_RSPLFA_SRVTYPE_IMP_EXEC
○ IF_RSPLFA_SRVTYPE_IMP_EXEC_REF
Das letztgenannte Interface ist relevant, wenn Sie bei
Ihrem Verfahren Referenzdaten benötigen. Die Imple
mentierung der Methoden der genannten Interfaces
ist optional, mit Ausnahme der Methode EXECUTE.
Zusätzlich kann die Klasse spezifische Prüfmethoden
implementieren, welche zur Laufzeit ausgeführt wer
den. Diesem Zweck dient das Interface
IF_RSPLFA_SRVTYPE_IMP_CHECK.
Sie können folgende Kennzeichen setzen:
○ Referenzdaten: Wenn das Kennzeichen gesetzt ist,
dann werden bei der Ausführung der Planungsfunk
tion Referenzdaten benötigt.
○ Ohne Blockbildung: Wenn das Kennzeichen gesetzt
ist, dann erfolgt die Verarbeitung der Bewegungsda
ten ohne Blockbildung, d.h. alle Merkmalsausprägun
gen in den Bewegungsdaten können geändert wer
den.
 Hinweis
In diesem Fall können keine Bedingungen ange
legt werden, da die Selektionstabelle jeder Bedin
gung nur Merkmale enthalten darf, die auch bei
der Blockbildung herangezogen werden können.
○ Nullsätze verarbeiten: Wenn das Kennzeichen nicht

gesetzt ist, dann werden während der Verarbeitung
alle Nullsätze ignoriert.
Oberfläche Merkmalsverwendung Sie können statt der Standardoberfläche der Merkmals

verwendung durch die Verwendung von WebDynpro- und
Entwicklungskomponenten eine eigene Oberfläche anle
gen. Zusätzlich können Sie folgende Kennzeichen setzen:
○ Spalte für zu verändernde Merkmale ausblenden: Die

ses Kennzeichen ist sinnvoll, wenn die Verarbeitung
ohne Blockbildungerfolgen soll, oder sich die zu ver
Planungskonzepte
Bildbereich Beschreibung
ändernden Merkmale aus anderen Einstellungen er

geben.
○ Beim Anlegen zuerst anzeigen: Wenn dieses Kennzei
chen gesetzt ist, wird beim Anlegen einer Planungs
funktion zuerst die Oberfläche der Merkmalsverwen
dung angezeigt, anderenfalls die Oberfläche mit den
Parameterwerten.
Oberfläche Parameter Sie können statt der Standardoberfläche der Parameter

durch die Verwendung von WebDynpro- und Entwick
lungskomponenten eine eigene Oberfläche anlegen.
2. Gehen Sie auf die Registerkarte Parameter.
Legen Sie die gewünschten Parameter über Parameter anlegen bzw. Komponente anlegen im Kontextmenü
eines Objektes in der Parameter-Hierarchie an. Die Details bereits vorhandener Parameter können Sie über
Eigenschaften im Kontextmenü ändern. Über und können Sie die Reihenfolge der Parameter
verändern. Die Reihenfolge der Parameter wird berücksichtigt, wenn Sie eine Planungsfunktion zu diesem
Planungsfunktionstyp anlegen.
Über das Kennzeichen Parameter ist tabellarisch können Sie einen Parameter als Tabelle kennzeichnen; er
verhält sich fortan wie eine interne Tabelle. In dieser besitzt jede Zeile des tabellarischen Parameters die
Eigenschaften, die dem ausgewählten Parametertyp entsprechen. Das Kennzeichen ist für alle
Parametertypen zugelassen (im Kontextmenü über Eigenschaften) mit Ausnahme der Kennzahlauswahl
oder wenn Parameter als Komponenten eines Strukturparameters dienen.
Parametertyp Beschreibung
Elementar Der Wert eines elementaren Parameters ist die Ausprä

gung eines bestimmten InfoObjects, d.h. jeder elementare
(Elementarer Parameter)
Parameter basiert auf einem InfoObject und erbt damit
dessen technische Eigenschaften. Wenn es sich bei dem
InfoObject um ein Merkmal handelt, prüft das System an
hand der Stammdaten automatisch die Gültigkeit eines
vom Anwender eingegebenen Wertes.
InfoObject des InfoProviders Der Parameter kann den Namen eines InfoObjects aus
dem aktuellen InfoProvider (Aggregationsebene) aufneh
men. Die dabei zulässigen InfoObjects bestimmen Sie
über die Auswahl Einschr. InfoObjekt:
○ Nur Kennzahlen sind zulässig.

○ Alle Merkmale
Nur Merkmale sind zulässig, diese aber ohne weitere
Einschränkung.
○ Nur Blockmerkmale
Blockmerkmale dienen der Gruppierung der Bewe
gungsdaten (siehe oben Ohne Blockbildung).
○ Nur zu verändernde Merkmale
Planungskonzepte
Parametertyp Beschreibung
Nur durch eine Planungsfunktion zu verändernde

Merkmale des InfoProviders sind zulässig, Block
merkmale sind also nicht zulässig.
○ Nur Bedingungsmerkmale
Nur in der Planungsfunktion für die Definition der Be
dingungen verwendete Merkmale sind zulässig.
Datenselektion Datenselektionsparameter können Selektionskriterien

mehrerer Merkmale aufnehmen, wie sie zur Definition von
Filtern benötigt werden. Es handelt sich also um eine spe
zielle Selektionstabelle. Die für die Datenselektion zulässi
gen Merkmale bestimmen Sie über die Auswahl Einschr.
Merkmale:
○ Alle Merkmale
Jedes Merkmal des InfoProviders ist zulässig.
○ Nur Blockmerkmale
Blockmerkmale dienen der Gruppierung der Bewe
gungsdaten (siehe oben Ohne Blockbildung).
○ Nur zu verändernde Merkmale
Nur durch eine Planungsfunktion zu verändernde
Merkmale des InfoProviders sind zulässig, Block
merkmale sind also nicht zulässig.
○ Nur Bedingungsmerkmale
Nur in der Planungsfunktion für die Definition der Be
dingungen verwendete Merkmale sind zulässig.
Struktur Mittels eines Strukturparameters können Sie andere Para

meter zu dessen Komponenten erklären und somit zu ei
(Strukturparameter)
ner Struktur zusammenfassen. Als Komponenten sind Pa
rameter vom Typ Elementar, InfoObject des InfoProviders
und Datenselektion zugelassen.
Um einen Parameter zu einer Komponente zu erklären,

wählen Sie entweder Komponente anlegen im Kontext
menü eines Strukturparameters oder dessen Komponen
ten, oder Eigenschaften Strukturparameter im

Kontextmenü eines anderen Parameters.
Kennzahlauswahl Dieser Parametertyp wählt die zu verarbeitenden Kenn

zahlen aus. Er ist damit ein Spezialfall des Typs InfoObject
des InfoProviders.
 Beispiel
Die von SAP ausgelieferten Planungsfunktionstypen basieren auf demselben technischen Konzept wie
kundeneigene Planungsfunktionstypen und können daher in der Pflege der Planungsfunktionstypen
angeschaut werden.
Planungskonzepte
 Beispiel
Der Funktionstyp Löschen (0RSPL_DELETE) ist ein einfaches Beispiel. Es gibt nur einen Parameter
(KYFSEL) zur Auswahl der zu löschenden Kennzahlen. In der zugehörigen ABAP-Klasse sind die beiden
Interfaces IF_RSPLFA_SRVTYPE_IMP_CHECK und IF_RSPLFA_SRVTYPE_IMP_EXEC implementiert.
1.8.2 Business-Logik für Planungsfunktionstyp auf der SAP

HANA-Datenbank implementieren
Indem Sie zusätzlich eine SQLScript-Procedure implementieren, können Sie einen kundeneigenen
Planungsfunktionstyp optimiert auf der SAP HANA-Datenbank ausführen lassen.
Voraussetzungen
● Sie haben einen Planungsfunktionstyp angelegt.

● Sie verwenden die SAP HANA-optimierte Prozessierung im SAP Business Planning and Consolidation,
version for SAP BW/4HANA, (Embedded-Konfiguration).
Kontext
Sie möchten für den neuen Planungsfunktionstyp im SAP BW∕4HANA-System eine ABAP-Klasse anlegen, das
relevante Interface implementieren und parametrisieren sowie vom SAP BW∕4HANA-System aus die
notwendigen Objekte auf der SAP HANA-Datenbank anlegen. Anschließend können Sie im SAP HANA-Studio
die SQLScript-Procedure implementieren.
Vorgehensweise
1. Legen Sie im Class Builder (Transaktionscode SE24) eine ABAP-Klasse an und implementieren Sie eines
der folgenden Interfaces:
○ IF_RSPLFA_SRVTYPE_TREX_EXEC muss implementiert werden, wenn keine Referenzdaten

verwendet werden,
○ IF_RSPLFA_SRVTYPE_TREX_EXEC_R muss implementiert werden, wenn Referenzdaten während der
Ausführung benötigt werden.
Zusätzlich kann die Klasse - wie im ABAP-Fall - spezifische Prüfmethoden implementieren, welche zur
Laufzeit ausgeführt werden. Diesem Zweck dient das Interface IF_RSPLFA_SRVTYPE_IMP_CHECK. Sie
können das Kennzeichen für Referenzdaten setzen: Wenn dieses Kennzeichen gesetzt ist, werden bei der
Ausführung der Planungsfunktion Referenzdaten benötigt.
Planungskonzepte
Die Implementierung der Methoden der genannten Interfaces ist optional, mit Ausnahme der Methode
trex_execute.
Die Methode init_and_check (vom Interface IF_RSPLFA_SRVTYPE_TREX_EXEC bzw.

IF_RSPLFA_SRVTYPE_TREX_EXEC_R) muss den Exporting-Parameter E_TREX_SUPPORTED auf ‘X’ bzw.
rs_c_true setzen, damit die SQLScript-Procedure aufgerufen wird.
Für die Methode if_rsplfa_srvtype_imp_exec_ref->get_ref_data_sel muss bei Referenzdaten

zumindest eine leere Methode angelegt werden.
 Achtung
Im Gegensatz zur ABAP-Implementierung muss man die Blockbildung der Bewegungsdaten in der
SQLScript-Procedure selbst implementieren, d.h. ohne weitere Implementierung können alle
Merkmalsausprägungen in den Bewegungsdaten geändert werden.
2. Rufen Sie aus Ihrer Implementierung die Interfacemethode if_rspls_sql_script ->

execute_sql_script auf, die die SQLScript-Procedure aufruft.
3. Implementieren Sie die SQLScript-Procedure, die durch die Interfacemethode if_rspls_sql_script -
> execute_sql_script aufgerufen werden soll.
 Achtung
Mit dem Parameter I_SQL_SCRIPT_RETURNS_AI (der Methode if_rspls_sql_script ->

execute_sql_script) kann gesteuert werden, ob die Ergebnisstabelle der Prozedur als Deltasätze
oder als Ergebnissätze weiterverarbeitet werden soll. Im Falle der Deltasätze werden die Werte aus der
Ergebnistabelle auf die Ausgangswerte aggregiert.
 Hinweis
Beachten Sie, dass die SQLScript-Procedure eine IN- und eine OUT-Tabelle benötigt, die beide die
Struktur der Aggregationsebene haben müssen. Falls Sie das Interface
IF_RSPLFA_SRVTYPE_TREX_EXEC_R implementiert haben, benötigt die SQLScript-Procedure für die
Referenzdaten eine weitere Tabelle mit derselben Struktur. Außerdem kann die SQLScript-Procedure
elementare IN-Parameter enthalten.
○ Wir empfehlen, die SQLScript-Procedure als AMDP (ABAP Managed Database Procedures) zu
implementieren, um diese Implementierung in das Transportwesen des AS ABAP zu integrieren. Damit
steht Ihnen für die SQLScript-Procedure dasselbe Transport- und Lifecycle-Management zur
Verfügung, wie Sie es von ABAP-Entwicklungsobjekten kennen. Außerdem vereinfacht dies die
Entwicklung insofern, als Sie keinen Zugang zum SAP HANA-Studio benötigen.
 Hinweis
Weitere Informationen über AMDP finden Sie in der ABAP - Schlüsselwortdokumentation im

Internet unter
○ http://help.sap.com/abapdocu_740/en/index.htm?file=abenamdp.htm
○ http://help.sap.com/abapdocu_740/de/index.htm?file=abenamdp.htm
○ Alternativ können Sie die SQLScript-Procedure im SAP HANA-Studio implementieren.

4. Das Programm RSPLS_SQL_SCRIPT_TOOL (Transaktionscode SE38) unterstützt Sie bei der
Implementierung der Klasse für den Planungsfunktionstyp bzw. bei der Implementierung eines SQL-
Planungskonzepte
Skripts. SQLScript erfordert eine typisierte Schnittstelle. Das SQLScript muss die Aggregationsebene
kennen, auf der das SQLScript operiert. Bei SQLScripten können eigene Parameter verwendet werden.
Dafür können Sie einen Strukturtyp angeben. Die Komponenten der Struktur werden als Parameter an das
SQLScript übergeben und können dort verwendet werden.
○ Auf der Registerkarte SQLScript-Implementierungen zeigen erhalten Sie einen Überblick über die
bereits vorhandenen Planungsfunktionen, bei denen ein SQLScript ausgeführt wird.
○ Auf der Registerkarte Beispiel-Planungsfunktionstyp können Sie sich Beispiel-Coding für AMDP-
Implementierungen für Planungsfunktionstypen erzeugen lassen. Dieses Coding können Sie in die
implementierende Klasse kopieren.
Für die Implementierung wird ein iterativer Prozess verwendet, um die implementierende Klasse und
den Planungsfunktionstyp anzulegen. Der Planungsfunktionstyp benötigt die Klasse. Die
Implementierung der Klasse muss die Einstellungen im Planungsfunktionstyp (die Parameter des
Planungsfunktionstyps) berücksichtigen.
Je nachdem wo sie in diesem iterativen Prozess stehen, können Sie den Coding-Vorschlag für eine
ABAP-Klasse oder für einen Planungsfunktionstyp erzeugen.
Zusätzlich zu der Parameterübergabe über eine Struktur können sie bei Planungsfunktionstypen auch
Parameter in einer Liste (Name, InfoObjekt, Wert) übergeben. In dem Beispiel-Coding wird diese
Möglichkeit vorgeschlagen (Aufruf von l_r_sql_script->get_parameter_values), um die Werte der
elementaren Parameter des Planungsfunktionstyps mit den Werten der Planungsfunktion in der
Tabelle l_t_iobj_param zu sammeln.
 Hinweis
Wenn Sie den Benutzer-Parameter (Transaktion SU3) SEO_SOURCEBASED_AMDP auf den Wert “X“
setzen, können Sie auch AMPD-Methoden im quelltextbasierten Klasseneditor (SE24 oder SE80)
bearbeiten.
○ Wir empfehlen, die SQLScript-Procedure als AMDP (ABAP Managed Database Procedures) zu
implementieren, um diese Implementierung in das Transportwesen des AS ABAP zu integrieren. Damit
steht Ihnen für die SQLScript-Procedure dasselbe Transport- und Lifecycle-Management zur
Verfügung, wie Sie es von ABAP-Entwicklungsobjekten kennen. Außerdem vereinfacht dies die
Entwicklung insofern, als Sie keinen Zugang zum SAP HANA-Studio benötigen.
Für AMDPs werden nur Quelltextabschnitte als Listenausgabe erstellt, die in die zu implementierende
Klasse eingefügt werden müssen.
○ Wenn Sie nicht AMDP verwenden, müssen Sie folgende Objekte im SAP HANA
○ -Studio eine Tabelle, deren Struktur mit der der Aggregationsebene übereinstimmt. Diese Tabelle
kann genutzt werden, um den Typ der Tabellenparameter in Ihrer SQLScript-Procedure
festzulegen.
○ den Körper der SQLScript-Procedure. Dieser Prozedurenkörper enthält die Tabellenparameter für
die Daten, die die Prozedur verändern soll, und die Rückgabetabelle mit dem Ergebnis der
Prozedur. Zusätzlich werden die elementaren Parameter der Funktion mit den entsprechenden
Typen in die Parameterliste aufgenommen.
 Hinweis
Für Tabellentypen und Procedures werden Objekte in SAP HANA angelegt, wenn der Test-
Parameter ausgeschaltet ist. Auf der Registerkarte SAP-HANA_Objekte können Sie auf SAP HANA
definierte Struktur-Typen und SQL-Prozeduren anzeigen, z.B. auch die AMDP-Methoden und die
dort im Interface verwendeten Strukturtypen. Sofern Sie SQL-Scripte für Planungsfunktionstypen
Planungskonzepte
direkt auf SAP HANA schreiben möchten, können Sie für diese einen leeren Prozedurkörper und
die notwendigen Typen hier erzeugen und auch wieder löschen.

Diese beiden Abschnitte erläutern den zweiten Schritt der Vorgehensweise, die Parametrisierung der
Interfacemethode -Studio anlegen: execute_sql_script.
1.8.2.1 Parameter der Interfacemethode

execute_sql_script
Die Interfacemethode if_rspls_sql_script -> execute_sql_script ruft die SQLScript-Procedure. Die

Tabelle gibt einen Überblick über die Parameter dieser Methode.
Parameter Typ Parameterart Beschreibung
I_VIEW Type Importing Setzen Sie i_view. Dies ist

der Importing-Parameter der
Methode TREX_EXECUTE.
I_VIEW_REF Type Importing Sofern Sie

IF_RSPLFA_SRVTYPE_TREX
_EXEC_R implementieren,
setzen Sie i_view_ref. Dies ist
I_T_IOBJ_PARAM Type Importing Jede Zeile in dieser Tabelle

stellt einen Parameter der
SQLScript-Procedure dar.
Die Felder sind folgende:
● NAME: Name des Para

meters
● IOBJNM: InfoObject,
das den Typ des Para
meters festlegt.
● VALUE: Parameterwert
Planungskonzepte
I_DB_SCHEMA_NAME Type Importing Schema, in dem die

SQLScript-Procedure ange
legt wurde.
Im Falle von AMDP überge

ben Sie diesen Parameter
nicht.
I_PROC_NAME Type Importing Name der SQLScript-Proce

dure
I_R_MSG Type Ref To Importing Setzen Sie i_r_msg. Dies ist

Methode TREX_EXECUTE
I_SQL_SCRIPT_RETURN Type Importing Standardwert ist ‘ ‘. Wenn Sie

S_AI den Standardwert belassen
oder explizit ‘ ‘ übergeben,
behandelt das System das
Ergebnis als Delta. - Die von
der Procedure berechneten
Daten werden zu den im Pla
nungsbuffer vorgehaltenen
Daten der Aggregations
ebene aggregiert.
Wenn Sie den Wert ‘X’ über

geben, wird das Ergebnis als
After Image behandelt.
I_T_ABAP_DATA Type Importing ABAP-Tabelle mit flacher

Struktur ohne Komponenten
von Typ-Referenz.
I_T_AGGR_VIEW Type Importing Optional können Sie eine

Liste von Aggregationsebe
nen zusammen mit Auswahl
kriterien übergeben. In
SQLScript kann auf diese Ag
gregationsebenen als Refe
renzdaten zugegriffen wer
den. Falls Daten einer sol
chen Aggregationsebene in
derselben Session geändert
werden, greift das System
auf die geänderten Daten zu.
I_T_HAAP_PARAS Type Importing Optional können Sie eine

Liste von SAP HANA-Analy
seprozessen übergeben.
Planungskonzepte
I_T_HAAP_PARAMETER_ Type Importing Um auf die Views der SAP

MAPPING HANA-Analyseprozesse zu
zugreifen, müssen Sie sog.
Platzhalter im SQL-State
ment verwenden. Mit dieser
Tabelle können Sie die Para
meternamen festlegen, mit
denen die Platzhalter ins
SQL-Script übergeben wer
den.
R_RESULT_VIEW Type Returning Übernehmen Sie den Rück

gabewert der Interfaceme
thode
if_rspls_sql_script ->
execute_sql_script in
den Returnwert r_s_view-
view der implementierten
1.8.2.2 Beispiel-Implementierung einer Interfacemethode

in SQLScript
Im folgenden finden Sie ein Beispiel für die Implementierung der Methode
if_rsplfa_srvtype_trex_exec_r ~ trex_execute.
Das nachfolgende Beispiel finden Sie in dem Programm RSPLS_SQL_SCRIPT_TOOL.
 Achtung
Beachten Sie, das Sie eine öffentliche Klasse (public class) implementieren müssen, damit diese Klasse
dem Planungsfunktionstyp zugewiesen werden kann.
 Beispielcode
METHOD if_rsplfa_srvtype_trex_exec_r~trex_execute.
DATA: l_r_sql_script TYPE REF TO if_rspls_sql_script,
l_procedure_name TYPE string,
l_srvtypenm TYPE rsplf_srvtypenm,
l_t_iobj_param TYPE if_rsr_pe_adapter=>tn_t_iobj_param.
Planungskonzepte
l_r_sql_script =
cl_rspls_session_store_manager=>get_sql_script_instance( i_r_store =
i_r_store ).
* The method if_rspls_sql_script~get_parameter_values returns a table of
parameters
* with the values given in the function definition
l_r_sql_script->get_parameter_values(
EXPORTING
i_r_param_set = i_r_param_set
i_para_name_for_procedure = 'HANA_PROCEDURE_NAME'
IMPORTING
e_procedure_name = l_procedure_name
e_t_iobj_param = l_t_iobj_param ).
* The function parameter given method paramenter i_para_name_for_procedure
* will not be returned in the table e_t_iobj_param but the value of this
* function parameter will be returned int the method parameter
e_procedure_name
* This mechanisme can e.g. be used to define function specific SAP HANA
procedure names.
* Other examples to get the name of the SAP HANA procedure name which will
be called can be
* - you use the technical name of the planning function type:
l_srvtypenm = p_r_srv->get_srvtypenm( ).
l_procedure_name = l_srvtypenm.
* - or you simply give the SAP HANA procedure name in a string:
l_procedure_name = 'MY_HANA_PROCEDURE'.
r_s_view-view = l_r_sql_script->execute_sql_script(
i_view = i_view
i_view_ref = i_view_ref
i_t_iobj_param = l_t_iobj_param
i_proc_name = l_procedure_name
i_r_msg = i_r_msg ).
ENDMETHOD. "IF_RSPLFA_SRVTYPE_TREX_EXEC_R~TREX_EXECUTE
1.9 Eingabebereite Query
Verwendung
Eingabebereite Queries können Sie verwenden, um Anwendungen für die manuelle Planung zu erstellen, die
von einer einfachen Datenerfassung bis zu komplexen Planungsanwendungen reichen. Weiterhin ermöglichen
eingabebereite Queries zur Laufzeit, Kurztexte in der Query zu bearbeiten, um z.B. Klassifikationen zu
verändern bzw. freie Kommentare zu Kennzahlwerten zu erfassen.
Planungskonzepte
Integration
Sie können die eingabebereiten Queries in verschiedenen Clients verwenden und ggf. mit weiteren Queries und
Planungsfunktionen zu komplexen Planungsanwendungen kombinieren.
Diese Links führen in die Dokumentation der BW-Modellierungswerkzeuge in Eclipse.
Dieser Link führt in die Dokumentation der Analysefunktionen des Analytic Managers.
1.9.1 Eingabebereite Queries zur Ausführungszeit
In Planungsanwendungen, die eine eingabebereite Query als Data Provider verwenden, bietet das System die
Möglichkeit, zur Laufzeit Daten manuell zu erfassen. Ob Zellen einer eingabebereiten Query zur
Ausführungszeit änderbar sind, hängt vom Query View und eventuell von weiteren Einstellungen (wie etwa von
Datenscheiben und Merkmalsbeziehungen) ab.
In Hinsicht auf die Eingabebereitschaft von Zellen eines Query Views beachten Sie die folgenden Regeln:
1. In einer Query, die für die manuelle Planung verwendet werden soll, ist eine Zelle nur dann eingabebereit,
wenn jeder Merkmalswert sämtlicher, in der Aggregationsebene enthaltener Merkmale eindeutig bestimmt
ist. Daraus folgt, dass alle hinsichtlich der Aggregationsebene aggregierten Werte nicht eingabebereit sind:
Summen, Teilsummen und innere Hierarchieknoten sind nicht eingabebereit.
2. Um auch Werte für berechnete Kennzahlen (wie z.B. Durchschnittspreis als Quotient aus Betrag und
Menge) ändern zu können, müssen diesen eingabebereite Formeln zugrunde liegen, und mindestens ein
Operand muss eingabebereit sein.
3. Um auch (hinsichtlich der Aggregationsebene) aggregierte Werte ändern zu können, müssen diese Werte
auf alle Datensätze disaggregiert werden, die zum aggregierten Wert der Zelle beitragen.
4. Wenn eine Query, die für die manuelle Planung verwendet werden soll, ein Navigationsattribut enthält, das
durch einen festen oder dynamischen Filter oder eine eingeschränkte Kennzahl eingeschränkt ist,
behandelt das System dieses Navigationsattribut als ein normales Merkmal. Dementsprechend wird die
unter Punkt 1 genannte Regel angewendet. Nur wenn das Navigationsattribut nicht eingeschränkt wird,
verhält sich das System so, als wäre das Navigationsattribut in der Query nicht enthalten.
5. In einer Query, die auf einem CompositeProvider oder einer komplexen Aggregationsebene definiert ist
und für die manuelle Planung verwendet werden soll, ist eine Zelle dann eingabebereit, wenn auf dem Weg
vom InfoProvider der Query zum planbaren Basis-InfoProvider genau eine Aggregationsebene beteiligt ist.
○ Wenn die Query auf einer komplexen Aggregationsebene definiert ist, muss der durch die Zelle
bestimmte Teilprovider ein planbarer Basis-InfoProvider sein.
○ Wenn die Query auf einem CompositeProvider definiert ist, muss der durch die Zelle bestimme
Teilprovider eine einfache Aggregationsebene auf einem planbarer Basis-InfoProvider sein.
In jedem Fall muss sich dann auch der planbare Basis-InfoProvider im Planmodus befinden.
6. Wenn eine eingabebereite Query im Änderungsmodus ausgeführt wird und die angeforderten Daten bereits
durch einen anderen Benutzer gesperrt sind, wird die Query im Anzeigemodus gestartet.
Planungskonzepte
Inverse Formel definieren [Seite 135]

Beispiele: Inverse Formel [Seite 142]
Inverse Formel zur Laufzeit [Seite 144]
Prozentfunktionen zur Laufzeit [Seite 147]
Beispiele: Inverse Formel zur Laufzeit [Seite 148]
Disaggregation (Top-Down-Verteilung) [Seite 125]
1.9.2 Alle gültigen Merkmalskombinationen anzeigen
Mit Merkmalsbeziehungen für planbare Basis-InfoProvider ist es möglich, die gültigen Kombinationen von
Merkmalswerten zu modellieren. Diese Information kann das System nutzen, um in eingabebereiten Queries
Merkmalskombinationen vorzuschlagen, für die noch keine Werte gesichert wurden.
Verwendung
Um nur die gültigen Kombinationen von Merkmalswerten zu erzeugen, verwendet das System aktuell genutzte
Werte aus dem Filter der Query und die Relationen aus den Merkmalsbeziehungen.
Voraussetzungen
● Sie haben Merkmalsbeziehungen modelliert.

● Sie haben eine eingabebereite Query definiert.
Vorgehensweise
Wenn Sie eine Query definieren, können Sie in den Eigenschaften eines Merkmals über Access Type for Result
Values die Zugriffsart für Ergebniswerte festlegen:
● Wenn Sie den Kombinationsvorschlag für die Planung nutzen möchten, wählen Sie die Option
Characteristic Relationships (Merkmalsbeziehungen). Falls ein Merkmal in einer Relation nicht enthalten
ist, greift das System auf die Stammdaten zurück, um die gültigen Kombinationen zu erzeugen. Da
Merkmalsbeziehungen für einen planbaren Basis-InfoProvider definiert werden, erzeugt das System für die
jeweils betroffenen planbaren Basis-InfoProvider die gültigen Kombinationen. Dabei werden auch die
technischen Merkmalsbeziehungen für Zeitmerkmale und Navigationsattribute berücksichtigt.
● Wenn Sie die Option Master Data (Stammdaten) wählen, erzeugt das System zunächst alle möglichen, nur
durch Zeitmerkmale und Navigationsattribute eingeschränkten Kombinationen. Dabei werden immer die
InfoObjekte aus demjenigen InfoProvider verwendet, auf dem die Query definiert ist. Durch diesen Prozess
Planungskonzepte
entstehen ggf. Datenzellen zu Merkmalskombinationen, die laut Merkmalsbeziehungen ungültig sind. Das
System prüft alle erzeugten Zellen; Zellen zu ungültigen Kombinationen sind nicht eingabebereit.
 Hinweis
Beachten Sie, dass bei den Optionen Characteristic Relationships bzw. Master Data leicht eine erhebliche
Anzahl von Kombinationen erzeugt werden kann. Setzen Sie entsprechend restriktiv für solche Merkmale
die Einschränkungen im Filter. Für Merkmalsbeziehungen können Sie pro planungsrelevanten Basis-
InfoProvider eine maximale Anzahl von Kombinationen angeben. Beachten Sie, dass
Merkmalsbeziehungen nicht als ein weiterer impliziter Filter für die zu lesenden Bewegungsdaten wirken.
Das System liest die durch den Filter der Query spezifizierten Bewegungsdaten (egal ob laut
Merkmalsbeziehung gültig oder nicht gültig) und erzeugt dann ggf. zusätzlich nach den oben erläuterten
Regeln weitere Kombinationen.
Beispiel
Für eine Absatzplanung planen Sie Mengen (ggf. rollierend) für die Perioden eines vorgegebenen Zeitintervalls
(z.B. ein Jahr). Die Produkte sind in einer Produkthierarchie enthalten, die Sie über Merkmalsbeziehungen
modelliert haben. Produkte gehören einer Produktgruppe an und diese wiederum einer Produktlinie. Verwenden
Sie diese Merkmale in den Zeilen einer eingabebereiten Query. In den Spalten verwenden Sie die Kennzahl
Absatzmenge und das Zeitmerkmal Geschäftsjahr/Periode im Aufriss. Für diese vier Merkmale wählen Sie
unter Zugriffsart für Ergebniswerte die Option Merkmalsbeziehungen. Dann erzeugt die System in den Zeilen
genau die gültigen Kombinationen; für das Merkmal Periode/Jahr er mittelt das System alle gültigen Perioden
aus den Stammdaten, die im Filter enthalten sind, und erzeugt entsprechend viele Kombinationen der
Kennzahlstruktur mit den Periodenwerten.
Planungskonzepte
Die folgende Graphik zeigt ein Beispiel für eine solche Planung:
 Hinweis
Beachten Sie, dass die Sonderperioden bei Geschäftsjahresvarianten gültige Stammdaten sind. Das
System wird im Fall der Selektion 1.2006 - 12.2007 bei Nutzung der Geschäftsjahresvariante K4 also auch
die Sonderperioden 13.2006 bis 16.2006 und die Periode 0.2007 vorschlagen. Wenn Sie diese Werte nicht
planen möchten, müssen Sie diese entsprechend aus der Selektion entfernen.

1.9.3 Disaggregation (Top-Down-Verteilung)

Die Disaggregation (auch: Top-Down-Verteilung) ist eine Hilfe zur manuellen Dateneingabe innerhalb der
manuellen Planung. Sie ermöglicht Ihnen innerhalb von eingabebereiten Queries die manuelle Eingabe auch bei
bezüglich einer Aggregationsebene aggregierten Werten.
Planungskonzepte
Eingabebereite Queries werden immer mit Bezug auf Aggragationsebenen definiert. Ohne die Funktionalität
der Disaggregation gilt, dass eine Zelle nur dann eingabebereit ist, wenn jeder Merkmalswert sämtlicher in der
Aggregationsebene enthaltener Merkmale eindeutig bestimmt ist. Somit ergibt sich, dass Zellen, die
aggregierte Werte hinsichtlich der Aggregationsebene enthalten, nicht eingabebereit sind. Dazu gehören
Summen, Zwischensummen und innere Hierarchieknoten.
Disaggregation ermöglicht es Ihnen, auch solche Werte, die hinsichtlich der Aggregationsebene aggregiert
sind, zu ändern. Dazu müssen die veränderten Werte auf alle Datensätze, die zum aggregierten Wert der Zelle
beitragen, top-down verteilt werden. Diese Top-down-Verteilung bezeichnen wir als Disaggregation.
 Achtung
Beachten Sie, dass die Disaggregation die vorhandene Planungsmodellierung nicht außer Kraft setzt: Neue
Datensätze und Delta-Datensätze werden immer auf der Grundlage der Aggregationsebene angelegt. Die
Disaggregation ist lediglich eine Hilfe für die manuelle Dateneingabe in eingabegereiten Queries.
Die Disaggregation in eingabebereiten Queries kann sich auf die Anwendungsmodellierung der Planung
auswirken, insbesondere im Bereich der Merkmalsbeziehungen.
Damit ein veränderter Wert einer Zelle der Query disaggregiert werden kann, muss das System alle Datensätze
bestimmen, die zum Wert der Zelle beitragen. Um diese Daten zu lesen, werden neben den bereits in den Zeilen
oder Spalten enthaltenen Merkmalen alle Merkmale der beteiligten Aggregationsebenen in den Aufriss
genommen. Wenn die Disaggregation in der Query genutzt werden soll, müssen also entweder Daten für die
Disaggregation vorhanden sein oder über Einstellungen der Query in der Disaggregation selbst erzeugt werden.
Das kann z.B. über die Einstellung zur Erzeugung von Kombinationen in der Query (laut Access Type for Result
Values, Zugriffsart für Ergebniswerte) erreicht werden. Achten Sie hierbei darauf, dass der Filter der Query so
eingeschränkt wird, dass die Anzahl der erzeugten Kombinationen in einem sinnvollen Rahmen bleibt.
Wenn Sie in der Defintion einer eingabebereiten Query die Einstellung Always Disaggregate Unposted Values
(Immer auf alle gültigen Kombinationen disaggregieren) wählen, überschreibt das System die Einstellungen
Zugriffsart für Ergebniswerte für jedes Merkmal. Das bedeutet, dass für jede Disaggregation alle gültigen
Kombinationen laut Merkmalsbeziehungen erzeugt werden und dann auf diese Kombinationen disaggregiert
wird. Das gilt auch dann, wenn die Query nur gebuchte Daten anzeigt. Diese Einstellung kann dann hilfreich
sein, wenn in der Planung die eingabebereiten Zellen i.a. leer sind, die Disaggregation jedoch auch ohne Daten
möglich sein soll. Achten Sie hierbei darauf, dass der Filter der Query so eingeschränkt wird, dass die Anzahl
der erzeugten Kombinationen in einem sinnvollen Rahmen bleibt. Ein typischer Anwendungsfall für diese
Einstellung ist eine Query, die nur bzgl. einem Zeitmerkmal verdichtet ist (Kostenstellen-Planung).
 Hinweis
Für Massendaten ist die Disaggregation in eingabegereiten Queries nicht konzipiert. Falls über
Disaggregation in der Query Massendaten verarbeitet werden sollen, empfehlen wir den Einsatz des Top-
Down-Planungsfunktionstyps.
Die Disaggregation steht nur für Basiskennzahlen mit der Aggregationsart SUM oder NO2 zur Verfügung, nicht
aber für berechnete Kennzahlen, Kennzahlen mit Ausnahmeaggregation, lokale Aggregationen und
Zeitkennzahlen. In der Query-Definition ist es möglich, das Disaggregationsverhalten eines bestimmten
Strukturelementes zu modellierung und zu parametrisieren:
Planungskonzepte
Modellierungsmöglichkeiten der Disaggregation
Basiskennzahlen mit der Aggregati Basiskennzahlen mit der Aggregati

Option onsart SUM onsart NO2
No Disaggregation: Keine Disaggrega x x

tion
Disaggregate Entered Value: Eingege x -

benen Wert disaggregieren
Disaggregate Difference to Entered x -

Value : Differenz disaggregieren
Disaggregate Copy: Eingegebenen - x

Wert kopieren
Art der Verteilung
Basiskennzahlen mit der Aggregati Basiskennzahlen mit der Aggregati

Option onsart SUM onsart NO2
Equally: Gleichverteilung x -
Same as in reference object (self refe x -

rence): Analogverteilung (zu sich
selbst)
Same as in reference object: Analog x -

verteilung (ein anderes Strukturele
ment)
Dieser Link führt in die Dokumentation der BW-Modellierungswerkzeuge in Eclipse.

Alle gültigen Merkmalskombinationen anzeigen [Seite 123]
SAP-Hinweis 994853
Diese Links bieten weitere Informationen über die Planungskonzepte.

Keine Disaggregation [Seite 128]
Eingegebenen Wert disaggregieren, Gleichverteilung [Seite 128]
Eingegebenen Wert disaggregieren, Analogverteilung (zu sich selbst) [Seite 129]
Eingegebenen Wert disaggregieren, Analogverteilung (zu folgendem Strukturelement) [Seite 130]
Differenz zu eingegebenem Wert disaggregieren, Gleichverteilung [Seite 130]
Differenz zu eingegebenem Wert disaggregieren, Analogverteilung (zu sich selbst) [Seite 131]
Differenz zu eingegebenem Wert disaggregieren, Analogverteilung (zu folgendem Strukturelement) [Seite 132]
Disaggregation Kopieren, homogene Werte [Seite 133]
Planungskonzepte
Disaggregation Kopieren, inhomogene Werte [Seite 133]
Disaggregation mit versteckten Referenzdaten [Seite 134]
Disaggregation zur Ausführungszeit: In diesen Abschnitten finden Sie einfache Beispiele, die verdeutlichen, wie
das System Werte gemäß der getroffenen Einstellungen verteilt.
1.9.3.1 Keine Disaggregation
Beispielszenario: Die Aggregationsebene enthält die Merkmale Produkt, Version, Geschäftsjahresariante,

Geschäftsjahr, Währung sowie die Kennzahl Betrag. Produkt ist in den Zeilen aufgerissen, alle anderen
Merkmale sind auf einen Wert beschränkt. In der Query wird für die Kennzahl Betrag die Einstellung Keine
Disaggregation gewählt.
Die folgende Tabelle zeigt das Ergebnis ohne Disaggregation:
Betrag (manuelle Ein Betrag (nach Ein

Produkt Betrag (Referenz) Betrag (vor Eingabe) gabe) gabe)
TFT 17" Monitor 1 20 20 20
TFT 19" Monitor 1 10 14 14
TFT 21" Monitor 1 0 2 2
Resultat 3 30 30 36
Die Resultatzeile ist nicht eingabebereit. Nur das Verändern der Werte in den eingabebereiten Zellen und der
Transfer dieser Werte aktualisiert die Resultatzeile.
1.9.3.2 Eingegebenen Wert disaggregieren,

Gleichverteilung

Merkmale sind auf einen Wert beschränkt. In der Query werden für die Kennzahl Betrag die Einstellungen
Eingegebenen Wert disaggregieren und Gleichverteilung gewählt.
Planungskonzepte
Die folgende Tabelle zeigt das Ergebnis dieser Disaggregation:

TFT 17" Monitor 1 20 20 12
TFT 19" Monitor 1 10 10 12
Resultat 3 30 36 36
Die Resultatzeile ist eingabebereit. Der Ergebniswert wurde von 30 in 36 geändert. Der Wert 36 wurde dann
gleichmäßig auf alle drei betroffenen Zellen verteilt (36/3 = 12).

Analogverteilung (zu sich selbst)

Eingegebenen Wert disaggregieren und Analogverteilung (zu sich selbst) gewählt.

TFT 17" Monitor 1 20 20 24
TFT 19" Monitor 1 10 10 12
Resultat 3 30 36 36
Die Resultatzeile ist eingabebereit. Der Ergebniswert wurde von 30 in 36 geändert. Der Wert 36 wurde dann
analog zur Gewichtung der bisherigen Betragswerte, also gewichtet, auf die Zellen verteilt. Im Ergebnis bleibt
der Wert für TFT 21" Monitor unverändert.
Planungskonzepte

Analogverteilung (zu folgendem Strukturelement)

Eingegebenen Wert disaggregieren und Analogverteilung (zu folgendem Strukturelement) gewählt.

TFT 17" Monitor 1 20 20 12
TFT 19" Monitor 1 10 10 12
Resultat 3 30 36 36
Die Resultatzeile ist eingabebereit. Der Ergebniswert wurde von 30 in 36 geändert. Durch die gewählte
Verteilungsart wurden die Werte in KennzahlBetrag (Referenz) als Referenz für die analoge Verteilung des
veränderten Wertes herangezogen. (In diesem Beispiel führte dies zu den gleichen Ergebnissen wie mit der
Einstellung Keine Disaggregation.)
Diese Modellierung ist am flexibelsten, wenn Sie die Kennzahl Betrag (Referenz) eingabebereit setzen.
Damit können Sie die Gewichtung für die Verteilung der Werte, die ja aus der Referenzspalte kommt, einstellen.
1.9.3.5 Differenz zu eingegebenem Wert disaggregieren,

Gleichverteilung

Planungskonzepte
Differenz zu eingegebenem Wert disaggregieren und Gleichverteilung gewählt.

TFT 17" Monitor 1 20 20 22
TFT 19" Monitor 1 10 10 12
Resultat 3 30 36 36
Die Resultatzeile ist eingabebereit. Der Ergebniswert wurde von 30 in 36 geändert. Diesmal wurde nicht der
neue Wert auf die betroffenen Zellen verteilt, sondern nur die Differenz des Wertes vor Eingabe und nach
manueller Eingabe, also 6. Da Verteilungsart Gleichverteilung gewählt wurde, werden alle betroffenen Zellwerte
um den Wert 6/3 = 2 modifiziert.

Analogverteilung (zu sich selbst)

Differenz zu eingegebenem Wert disaggregieren und Analogverteilung (zu sich selbst) gewählt.

TFT 17" Monitor 1 20 20 24
TFT 19" Monitor 1 10 10 12
Resultat 3 30 36 36
Planungskonzepte
manueller Eingabe, also 6. Die 6 wurde dann analog der bisherigen Zellenwerte, also gewichtet, auf die Zellen
verteilt. Das Ergebnis entspricht der Disaggragation mit den Einstellungen Eingegebenen Wert disaggregieren
und Analogverteilung (zu sich selbst).

Analogverteilung (zu folgendem Strukturelement)

Differenz zu eingegebenem Wert disaggregieren und Analogverteilung (zu folgendem Strukturelement) gewählt.

TFT 17" Monitor 10 20 20 20 + 2 = 22
TFT 19" Monitor 0 10 10 10 + 0 = 10
TFT 21" Monitor 20 0 0 0+4=4
Resultat 30 30 36 36
manueller Eingabe, also 6. Durch die gewählte Verteilungsart wurden die Werte in KennzahlBetrag
(Referenz) als Referenz für die analoge Verteilung des veränderten Wertes herangezogen.
Planungskonzepte
1.9.3.8 Disaggregation Kopieren, homogene Werte
In diesem Beispiel wird die Disaggregation Kopieren für die Kennzahl Preis verwendet. Preis ist eine Basis-
Kennzahl mit der Aggregation NO2 (keine Aggregation) und hat für alle Produkte homogene Werte.
Die Werte für Preis sind für alle Produkte gleich 10. Daher ist der Ergebniswert ebenfalls 10.
Preis (manuelle Ein

Produkt Betrag (Referenz) Preis (vor Eingabe) gabe) Preis (nach Eingabe)
TFT 17" Monitor 10 10 10 36
TFT 19" Monitor 0 10 10 36
TFT 21" Monitor 20 10 10 36
Resultat 30 10 36 36
Die Resultatzeile ist eingabebereit. Der Ergebniswert wurde von 10 in 36 geändert. Der Wert 36 wurde dann auf
alle in den Ergebniswert eingehenden Zellen kopiert.
1.9.3.9 Disaggregation Kopieren, inhomogene Werte
In diesem Beispiel wird die Disaggregation Kopieren für die Kennzahl Preis verwendet. Preis ist eine Basis-
Kennzahl mit der Aggregation NO2 (keine Aggregation) und hat keine homogene Werte für die verschiedenen
Produkte.
Die Werte für Preis sind für alle Produkte verschieden. Daher ist der Ergebniswert ‘*’ (oder ‘NOP’
bzw. ‘NONEX’).
Preis (manuelle Ein

TFT 17" Monitor 10 10 10 36
TFT 19" Monitor 0 20 20 36
Planungskonzepte
Preis (manuelle Ein
Resultat 30 * 36 36
Die Resultatzeile ist eingabebereit. Der Ergebniswert wurde von ‘*’ (für inhomogene Werte) in 36 geändert. Der
Wert 36 wurde dann auf alle in den Ergebniswert eingehenden Zellen kopiert.
1.9.3.10 Disaggregation mit versteckten Referenzdaten

Eingegebenen Wert disaggregieren und Gleichverteilung gewählt.
Allen bisherigen Beispielen ist gemeinsam, dass die Referenzdaten für die Verteilung in der Query View
vorhanden sind. Im praktischen Einsatz ist dies aber oft nicht der Fall. Das kann zu scheinbar falschen
Resultaten führen. Das folgende Beispiel enthält einen solchen scheinbaren Fehler, ist in Wahrheit aber richtig.
Folgende Daten werden angenommen; alle nicht erwähnten Merkmale haben einen festen Wert.
Produkt Geschäftsjahr Betrag
TFT 17" Monitor 2007 0
Folgend wird die gleiche Query View wie oben dargestellt, d.h. das MerkmalGeschäftsjahr ist nicht
aufgerissen. Das Ergebnis ist:

Planungskonzepte
Resultat 0 0 6 0
Wir nehmen an, die Verteilungsart Gleichverteilung sei gewählt. Wenn die Resultatzeile von 0 in 6 geändert wird,
dann werden die Werte wie in der Tabelle dargestellt verteilt, da das System alle Datensätze liest, die zum
Ergebniswert beisteuern. Für jedes Produkt gibt es eine verschiedene Anzahl von Datensätzen. Im Ergebnis
werden die Werte nach der Aggregation überGeschäftsjahr in Hinsicht auf Produkt nicht gleichverteilt,
obwohl das System die Verteilungsart Gleichverteilung nutzt.
 Hinweis
In obiger Situation hätte ein Aufriss nach Geschäftsjahr alle Datensätze sichtbar machen können, die für
die Verteilung herangezogen wurden. Sofern die Query nicht zu groß istm, kann diese Technik helfen, das
Ergebnis besser zu verstehen.
1.9.4 Inverse Formel definieren
Verwendung
Eingabebereite Formeln, inverse Formel und Formelgruppe
Im folgenden Abschnitt wird die Definition inverser Formeln mit Hilfe einer mathematischen Notation genau
beschrieben.
 Hinweis
Beispiele für inverse Formeln finden Sie unter Beispiele: Inverse Formel [Seite 142] sowie im SAP-Hinweis
1236347 .
Um eine inverse Formel genau beschreiben zu können, legen wir zunächst eine Notation fest. Wir nehmen an,
F = F(op1, ..., opn)
ist eine Formel mit den Operanden op1 bis opn. Wenn diese Formel eingabebereit ist, nennen wir die Formel F
Träger einer Formelguppe. Die Formelgruppe besteht (laut Definition) aus den Operanden op1 bis opn und der
Formel F.
Planungskonzepte
Für eingabebereite Formeln, inverse Formeln und Formelgruppen gelten folgende Regeln, die in der Query-
Definition oder zur Generierungszeit der Query vom System überprüft werden:
FG1: Folgende Objekte sind als Operanden opi, i = 1, ..., n für eine eingabebereite Formel F erlaubt:
1. Basis-Kennzahlen oder eingeschränkte Kennzahlen

2. Konstanten oder 'Reporting'-Formeln; das sind Formeln, die während eines Server-Roundtrips aufgrund manueller Än
derungen ihren Wert nichtändern
3. Träger einer anderen Formelgruppe G, wobei F ≠G und G nicht %GT (Prozentualer Anteil an der Gesamtsumme), %XT
(Normieren auf Ergebnis entlang der Spalten), %YT (Normieren auf Ergebnis entlang der Zeilen)
FG2: Wenn der Operand opi eingabebereit ist, muss man im Query Designer eine inverse Formel definieren, die opi aus den
folgenden Operanden berechnet: F, op1, ..., op(i-1), op(i+1), ..., opn.
FG3: Sämtliche Elemente der Formelgruppe müssen entweder in der Kennzahl-Struktur oder in Ausnahmezellen enthalten
sein; der letztgenannte Fall ist nur für Queries mit zwei Strukturen von Bedeutung.
Ausnahmefall: %GT (Prozentualer Anteil an der Gesamtsumme), %XT (Normieren auf Ergebnis entlang der
Spalten), %YT (Normieren auf Ergebnis entlang der Zeilen)
Wenn Sie den prozentualen Anteil an der Gesamtsumme berechnen möchten, wählen Sie die Formel F= %GT.
In diesem Fall ist nur ein Operand erlaubt. Dieser Operand muss eine Basis-Kennzahl oder eine eingeschränkte
Kennzahl mit eingeschalteter Disaggregation sein. Sie brauchen keine inverse Formel zu definieren. Dieselben
Regeln gelten für %XT und %YT.
Hinweise
● Wenn Sie in der Query-Definition inverse Formeln anlegen, überprüft das System, zu welchen Operanden
inverse Formeln angelegt werden müssen und legt eine entsprechende Liste an. Per Doppelklick auf eine
inverse Formel gelangen Sie auf das Bild Formel ändern. Das System zeigt unter Verfügbare Operanden
eine Liste aller erlaubten Operanden für die Umstellung der Formel an.
● Die inverse Formel zu einem eingabebereiten Operanden einer eingabebereiten Formel entsteht durch das
Auflösen der Formel nach dem eingabebereiten Operanden.
● Man kann eingabebereite Formeln auch in einer wieder verwendbaren Struktur definieren. Dann müssen
auch alle Elemente der Formelgruppe in der wieder verwendbaren Strukturen liegen.
● In einer Query mit eingabebereiten Formeln dürfen die Kennzahlen nicht nur im Filter der Query enthalten
sein.
● Das System unterstützt das Verketten von Formeln; Formeln können auch Schnittmengen haben und in
anderen Formeln enthalten sein. Eine Schachtelung muss zyklenfrei sein.
 Achtung
Beachten Sie, dass eine eingabebereite oder inverse Formel, sobald sie eine Formelvariable vom Typ
Ersetzungspfad enthält, nicht geschachtelt werden darf, damit das System die Variable durch die
Stammdatenattribute eines Merkmals in jedem Falle richtig ersetzen kann.
● Inverse Formeln sind technische Objekte, die für Invertierung von eingabebereiten Formeln benötigt
werden. Daher haben inverse Formeln auf der Registerkarte General zur Einstellung Display die
Voreinstellung Immer Ausblenden. Zur Fehlersuche kann es hilfreich sein, diese technischen Formeln
einzublenden.
Besonderheiten bei Queries mit zwei Strukturen
Planungskonzepte
Um die Verwendung von Formeln in Queries mit zwei Strukturen genau beschreiben zu können, legen wir
zunächst eine Notation fest.
Wir nehmen an, eine Query enthält zwei Strukturen X und Y:
X enthält die Elemente X1, ..., Xm und wird in den Spalten dargestellt.
Y enthält die Elemente Y1, ..., Yn und wird in den Zeilen dargestellt. Y enthält die Kennzahlen.
Die Kreuzungspunkte von zwei Strukturkomponenten Yi und Xk sind Zellen, die wir mit Yi/Xk = cik bezeichnen.
Diese Zellen werden immer vom System generiert. Im Zelleditor der Query-Definition können Sie diese Zellen
allerdings als sog. Ausnahmezellen ausdrücklich definieren. Ausnahmezellen können vom Typ Zellreferenz,
Selektion oder Formel sein.
Die folgende Tabelle veranschaulicht Zellen, die durch die Verwendung der beiden Strukturen X und Y
entstehen:
Y/X X1 ... Xi ... Xm
Y1 C11 C1j C1m
...
Yi Ci1 Cij Cim
...
Yn Cn1 Cni C
nm
Wir nehmen an, dass Yn = F = F(Y1, ..., Yk) der Träger einer Formelgruppe ist, d.h. k < n und Yn ist eine
eingabebereite Formel. Die Operanden Y1, ..., Yk haben einen der Typen, die oben unter Regel FG1 genannt
wurden. Wie die Notation bereits zeigt, müssen alle eingabebereiten Operanden in der Zeilenstruktur Y
enthalten sein. Daraus ergibt sich die erste Regel:
C1: Wenn eine Query zwei Strukturen und keine Ausnahmezellen hat, können eingabebereite Formeln und inverse Formeln
nur in einer Struktur definiert werden, d.h. alle eingabebereiten und inversen Formeln müsen in der Kennzahlstruktur
enthalten sein.
Die Regel C1 ist eine Umschreibung der Regel FG3.
Die tatsächlich zu berechnenden Formeln in den Zellen der Zeile Yn für die Spalte Xj in der oben stehenden
Tabelle kann man herleiten, indem man die Operanden Y1, ...Yk durch die korrespondieren Zellen c1j, ckj
ersetzt. Für die inversen Formeln gilt dasselbe.
Beispiel
Wie nehmen an, n = 3 und Y3 = Y2 / Y1, d.h. Y3 ist der Durchschnittspreis, Y2 ist Umsatz und Y1 ist Menge.
Weiterhin nehmen wir an, m = 3 und X1, X2 haben den Typ Selektion, enthalten z.B. Einschränkungen nach
dem Merkmal Vorgangsart wie etwa Kundenauftrag und Abrechnungsdaten in einem Szenario der
Ergebnisrechnung. X3 enthält die Formel X3 = X1 + X2.
Planungskonzepte
Y/X X1 X2 X3 = X1 + X2
Y1 C11 C12 C13 = C11 + C12
Y2 C21 C22 C23 = C21 + C22
Yn C31 = C21 / C11 C32 = C21 / C12 1. C33 = C13 / C23

2. C33 = C31 + C32
Wie dieses Beispiel zeigt, müssen wir festlegen, ob Kreuzungspunkte zwischen eingabebereiten Formeln und
Reporting-Formeln eingabebereit sein können und dort ggf. inverse Formeln berechnet werden können.
Mit einer allgemeineren Notation nehmen wir an, dass Xm eine Formel ist; in diesem Fall muss eine
Vorrangregel für die Kreuzungspunkte Yn = F und Xm festgelegt werden. Ohne eine solche Regel nimmt das
System das zuletzt gesicherte Strukturelement. Auf der Registerkarte Erweitert für das Strukturelement Yn
oder Xm können Sie festlegen, ob das System diese Formel oder die Formel aus der anderen Struktur für die
Berechnung anwenden soll.
Aber Yn ist eine eingabebereite Formel, und es gibt inverse Formeln für die eingabebereiten Operanden Y1, ...,
Yk. Wie das Beispiel zeigt, spielt es am Kreuzungspunkt von Yn und Xm keine Rolle, ob das System im
Kreuzungspunkt Yn/Xm die von Yn oder von Xm kommende Formel berechnet: Die Zelle Yn/Xm kann nicht
eingabebereit sein, da dann auch eine Formelinversion für diese Zelle benötigt würde. Da aber Xm eine
Reporting-Formel ist und keine Inversion hat, kann es hierfür auch keine Inversion geben. Daraus ergibt sich die
zweite Regel:
C2: Der Kreuzungspunkt einer inversen Formel und einer nicht eingabebereiten Formel ergibt eine nicht eingabebereite Zelle.
Das hängt nicht von den Einstellungen der Formelpriorität der eingabebereiten Formel oder der Formel aus der anderen
Struktur ab. Im Ergebnis verwendet das System für diese Kreuzungspunkte keine inversen Formeln.
In den oben genannten Fällen wurden keine Ausnahmezellen verwendet. Im folgenden soll beschrieben werden,
wie sich das System verhält, wenn Ausnahmezellen cij in der Formel F = F(c1j, ..., ckj) verwendet werden, wobei
die Variablen folgendes bedeuten:
i = 1, ..., k sind die Indizes der Operanden der eingabebereiten Formel F, die in der Zeilenstruktur Y enthalten ist,
j ist der Index eines Strukturelementes der Spaltenstruktur X
C3: Wenn F eine eingabebereite Formel in der Kennzahlenstruktur Y und Yi ein Operand der Formel F in der Struktur Y ist,
könnenAusnahmezellen für die Kreuzungspunkte Yi/Xj von Yi mit Xj nach den folgenden Regeln so definiert werd en, dass die
eingabebereiten Formeln nicht zurückgesetzt werden:
1. Wenn Yi nicht eingabebereit ist, kann die Ausnahmezelle cij einen der folgenden Typen haben: nicht eingabebereite Se
lektion, nicht eingabebereite Formel
2. Wenn Yi eine eingabebereite Formel ist (oder ggf. auch ineinander verschachtelte eingabebereite Formeln), wird die
oben genannte Regel 1. auf die Operanden von Yi angewendet. Das ist daher möglich, weil auch die Operanden von Yi in
der Kennzahlstruktur Y enthalten sind (siehe Regel FG3).
Planungskonzepte
Mit Rücksicht auf die oben genannte Regel FG3 gibt es noch einen Fall:
C4: Wenn es in der Kennzahlstruktur keine eingabebereite Formel gibt, kann eine eingabebereite Formel F nur in einer
Ausnahmezelle definiert werden. Sämtliche Operanden der Formel müssen Ausnahmezellen sein. Für die Formel F und ihre
Operanden gelten dann die Regeln FG1, FG2, FG3, wenn folgende Ersetzungen durchgeführt werden:
1. Basis-Kennzahl bzw. eingeschränkte Kennzahl ist zu ersetzen durch Ausnahmezelle vom Typ Selektion oder Zellrefe
renz vom Typ Selektion.
2. Nicht eingabebereite Formel ist zu ersetzen durch Ausnahmezelle vom Typ (nicht eingabebereite) Formel oder Zellrefe
renz vom Typ (nicht eingabebereite) Formel.
Hinweise
● Die in der Query-Definition getroffenen Einstellungen für eingabebereite Formeln können durch andere
Einstellungen zur Laufzeit überschrieben werden. Eingabebereitschaft zur Laufzeit wird von den
Operanden des Trägers der Formelgruppe geerbt. Wenn z.B. sämtliche Operanden einer eingabebereiten
Formel nicht eingabebereit sind, kann auch die Formel selbst nicht eingabebereit sein.
● Eine Formel als Träger einer Formelgruppe hat keine eigene Disaggregationseinstellung. Wenn Werte für
eingabebereite Formeln geändert werden, rechnet das System stets auf die zugrunde liegenden Basis-
oder eingeschränkten Kennzahlen zurück, wobei letztere durchaus Disaggregationseinstellungen haben
können. Im Ergebnis wird das Disaggregationsverhalten von eingabebereiten Kennzahlen also implizit
durch die Basis-Kennzahlen festgelegt, die in der Formeldefinition enthalten sind.
 Empfehlung
Wir empfehlen, ineinander geschachtelte Formelgruppen zu vermeiden, da der Anwender bei diesen
die Rechenfolge meist nicht einfach ablesen kann.
 Achtung
Beachten Sie, dass zur Laufzeit im Rahmen der Berechnung von eingabebereiten und inversen Formeln
Rundungen durchgeführt werden. Die Anzeigeeinstellungen haben keinen Einfluss auf die Rundungen.
Diese werden stets im Hinblick auf die von dem entsprechenden Datenbankfeld vorgegebene höchste
Genauigkeit vorgenommen.
Spezielle Formelgruppe für die Prozentfunktion %GT, %XT, %YT
Die Prozentfunktion %GT (Prozentualer Anteil an der Gesamtsumme) ist eine spezielle Formelgruppe, für die
keine inversen Formeln definiert zu werden brauchen. Wenn die Formel %GT(op) verwendet wird, muss der
Operand op eingabebereit und entweder eine Basis- oder eine eingeschränkte Kennzahl mit eingeschalteter
Disaggregation sein. Es ist nicht erlaubt, eingabebereite Formeln, die die Prozentfunktion %GT enthalten,
ineinander zu verschachteln.
Dieselben Regeln gelten für die Prozentfunktionen %XT (Normieren auf Ergebnis entlang der Spalten) und %YT
(Normieren auf Ergebnis entlang der Zeilen). Diese Funktionen errechnen den Prozentwert des Operanden mit
Rücksicht auf die nächst höhere Zwischensumme auf der X-, d.h. Spaltenachse bzw. auf der Y-, d.h.
Zeilenachse.
 Beispiel
Wir nehmen an, ein Unternehmen verkauft an zwei Kunden A und B zwei Produkte (Produkt 1 und Produkt
2):
Planungskonzepte
Umsatz
Summe der Umsätze aller
Produkt 1 Produkt 2 Produkte pro Kunde
Kunde A 20 40 60
Kunde B 80 40 120
Summe der Umsätze aller 100 80 180

Kunden pro Produkt
● Der Wert 20 entspricht einem Anteil von 33,3% bezogen auf die Summe der Umsätze aller Produkte
pro Kunde A (nämlich 60); dies errechnet die Formel %XT (enlang der Spalten).
● Der Wert 20 entspricht einem Anteil von 20% bezogen auf die Summe der Umsätze aller Kunden pro
Produkt 1 (nämlich 100); dies errechnet die Formel %YT (entlang der Zeilen).
 Achtung
Falls eine SAP BW∕4HANA-Hierarchie auf der X-Achse verwendet wird, berechnet die Formel %XT den
Prozentwert des Operanden mit Rücksicht auf den Wurzelknoten der Hierarchie und nicht mit Rücksicht
auf den nächsten Vaterknoten der Hierarchie. Entsprechendes gilt für den Fall, dass eine Hierarchie auf der
Y-Achse und die Formel %YT verwendet wird.
Rechenmodus und Formelpriorität
 Hinweis
Der Rechenmodus legt fest, wann das System beginnen soll, inverse Formeln auszurechnen. Sie können
den Rechenmodus in den Eigenschaften der Query auf der Registerkarte General, Bildbereich Planning
festlegen.
Es gibt folgende Möglichkeiten:
Berechnung von inversen Formeln Beschreibung
Kennzeichen ist nicht gesetzt Initialer Rechenmodus: Dies ist die Standardeinstellung. Zur
Laufzeit der Query berechnet das System inverse Formeln,
wenn mindestens ein Wert einer eingabebereitenFormel fi-
xiert oder manuell geändert wurde.
Kennzeichen ist gesetzt Symmetrischer Rechenmodus: Zur Laufzeit der Query be
rechnet das System inverse Formeln, wenn mindestens ein
Element einer eingabebereitenFormel fixiert oder manuell
geändert wurde.
Planungskonzepte
Abhängig von dem gewählten Rechenmodus können Sie die Formelpriorität für alle inversen Formeln einer
eingabebereiten Formel wie folgt festlegen:
Rechenmodus Beschreibung
Initialer Rechenmodus Unter der eingabebereiten Formel finden Sie alle inversen
Formeln, die zu den eingabebereiten Operanden der Träger
formel angelegt wurden. Die Reihenfolge der inversen For
meln in dieser Liste bestimmt die Formelpriorität. Das
oberste Element hat die höchste Priorität.
Symmetrischer Rechenmodus Unter der eingabebereiten Formel finden Sie alle inversen
Formeln, die zu den eingabebereiten Operanden der Träger
formel angelegt wurden, sowie die Trägerformel. Die Reihen
folge der inversen Formeln in dieser Liste bestimmt die For
melpriorität. Das oberste Element hat die höchste Priorität.
Infolge dessen hat die Trägerformel nicht, wie im initialen Re
chenmodus, stets die höchste Priorität, sondern kann auch
eine niedrigere Priorität erhalten.
Wenn das System eine Formelgruppe zur Laufzeit berechnet und weder manuelle Eingabe noch fixierte Zellen
oder vorangegangene Berechnungen eindeutig die Reihenfolge der Berechnungen bestimmen, berechnet das
System die inverse Formel mit der höchsten Priorität.
Hinweis für Berechnung
Der Hinweis für Berechnung ist eine Eigenschaft der Formelgruppe. Wenn Sie dieselben Operanden in
verschiedenen eingabebereiten Formeln verwenden, ist ggf. nicht eindeutig festgelegt, in welcher Reihenfolge
die Formelgruppen abgearbeitet werden sollen. Sie können dies vermeiden, indem Sie die Priorität der
Formelgruppen mit Hilfe von ganzen Zahlen im Feld Hinweis für Berechnung festlegen. Je niedriger der Wert,
desto höher ist die Priorität der Formelgruppe. Für verschiedene Formelgruppen kann auch derselbe Wert für
die Priorität vergeben werden; die Prioritäten dürfen auch Lücken enthalten.
Der Hinweis für Berechnung ist keine absolute, sondern eine relative Einstellung. Wie diese Einstellung die
Reihenfolge der Formelgruppen bestimmt, hängt auch vom Kontext ab, z.B. von den geänderten, fixierten oder
berechneten Zellwerten. In der Regel ist es nicht nötig, die Formelgruppenpriorität über den Hinweis für
Berechnung ausdrücklich festzulegen.

Eingabebereite Queries zur Ausführungszeit [Seite 122]
Inverse Formel zur Laufzeit [Seite 144]
Diese Links führen in die Dokumentation des Konzeptes der eingabebereiten Query.
Planungskonzepte
1.9.4.1 Beispiele: Inverse Formel
Verwendung
Im folgenden wird an Hand einiger einfacher Beispiele verdeutlicht, wie das System Werte gemäß der in der
Query-Definition zu einer eingabebereiten Formel definierten inversen Formeln berechnet.
 Hinweis
Die Beschreibung mit Hilfe einer mathematischen Notation und die Regeln im einzelnen finden Sie unter
Inverse Formel definieren [Seite 135]. Weitere Beispiele finden Sie im SAP-Hinweis 1236347.
Beispiel 1: Durchschnittspreis
Das erste Beispielszenario ist folgendes: Sie möchten mit folgenden Kennzahlen planen: Menge, Umsatz und
Durchschnittspreis. Die Kennzahl Durchschnittspreis wird wie folgt berechnet:
'Durchschnittspreis' = NDIV0( 'Umsatz' / 'Menge' )
 Hinweis
Um Fehler aufgrund einer Division durch Null zu vermeiden, verwenden wir hier die Funktion NDIV0.
Da die Kennzahl Durchschnittspreis eine berechnete Kennzahl ist und eingabebereit sein soll, benötigt das
System Regeln, die beschreiben, wie eine Änderung des Wertes des Durchschnittpreises entweder auf die
Menge oder auf den Umsatz zurückgerechnet werden soll. Diese Regeln werden durch inverse Formeln
festgelegt. Das System benötigt eine inverse Formel für jeden Operanden der eingabebereiten Formel
Durchschnittspreis.
Wir nehmen an, dass beide Operanden, Menge und Umsatz, eingabebereite Kennzahlen sind. In diesem Fall
müssen Sie folgende inverse Formeln definieren:
'Umsatz' = 'Durchschnittspreis' * 'Menge'
und
'Menge' = NDIV0( 'Umsatz' / 'Durchschnittspreis' )
 Hinweis
Falls nur der Wert für den Durchschnittspreis geändert wird, ist es zunächst nicht eindeutig, ob das System
auf die Menge oder auf den Umsatz zurückrechnen soll. In diesem Fall wendet das System die inverse
Formel mit der höchsten Priorität an. Die Formelpriorität wird durch die Anordnung der inversen Formeln in
der Formelgruppe bestimmt: Die Formel mit der höchsten Priorität steht an oberster Stelle in der Liste der
inversen Formeln.
Beispiel 2: Prozentualer Anteil
Planungskonzepte
Das zweite Beispielszenario ist folgendes: Sie möchten mit folgenden Kennzahlen planen: Betrag und
prozentualer Anteil des Betrages in Hinsicht auf die Gesamtsumme. Der prozentualer Anteil soll ebenfalls
eingabebereit sein.
Dieser Fall kann wie Beispiel 1 mit einer eingabebereiten Formel und der Definition einer inversen Formel
modelliert werden. Daneben gibt es aber auch die Möglichkeit, die Funktion '%GT' (d.h. prozentualer Anteil an
der Gesamtsumme) mit einigen zusätzliche Funktionen zu nutzen:
● Wenn Sie die Funktion %GT verwenden, brauchen Sie keine inverse Formel anzulegen, das diese im System
bereits definiert ist.
● Die Gesamtsumme bezüglich des Operanden von %GT ist während der Berechnung der inversen Formel
automatisch fixiert. Damit wird vom System sichergestellt, dass sich der veränderte %-Wert nach einem
Server-Roundtrip nicht verändert.
● Die Funktion %GT ist dann sinnvoll, wenn die zugrunde liegende Basiskennzahl eine der unterstützten
Disaggregationseinstellungen nutzt. Weitere Informationen über die möglichen
Disaggregationseinstellungen finden Sie unter Eingabebereite Query [Seite 121].
Definieren Sie folgende Formel:
'% Anteil' = %GT 'Betrag'
Wählen Sie die Option Eingabebereit. Eine inverse Formel brauchen Sie nicht anzulegen.
Beispiel 3: Symmetrischer Rechenmodus und Durchschnittspreis
Formeln werden immer dann berechnet, wenn der OLAP-Prozessor ein neues Ergebnis berechnet.
Wenn der Wert einer eingabebereiten Formel geändert wird, z.B. der Wert der berechneten Kennzahl
Durchschnittspreis, muss das System die inverse Formel ausrechnen. In diesem Fall berechnet das System
entweder die Formel für Umsatz oder die Formel für Menge.
Wenn jedoch der Wert eines Operanden einer eingabebereiten Formel wie z.B. der Kennzahl Umsatz geändert
wird, berechnet das System keine inversen Formeln. Das System errechnet einen neuen Durchschnittspreis,
wenn der OLAP-Prozessor das Ergebnis aktualisiert.
Es gibt Anwendungsfälle, in denen ein anderes Verhalten erwünscht ist: Wenn der Wert eines Operanden wie
z.B. der Kennzahl Umsatz geändert wird, soll der Wert für den Durchschnittspreis beibehalten und die
Änderung auf die Kennzahl Menge zurückgerechnet werden. Dieses Verhalten können Sie mit dem sog.
symmetrischen Rechenmodus erreichen.
 Hinweis
Um den symmetrischen Rechenmodus einzuschalten, wählen Sie bei der Query-Definition in den
Eigenschaften der Query auf der Registerkarte General, Bildbereich Planung die Eigenschaft Symmetrical
Calculation Mode.
Sinnvoll ist dieser Modus insbesondere in komplexen Szenarios, die mit vielen verschachtelten eingabebereiten
Formeln arbeiten, um die geforderte Geschäftslogik abzubilden. In solchen Szenarios kann es sinnvoll sein, eine
Möglichkeit zu haben, um ausdrücklich festzulegen, in welcher Reihenfolge die Berechnungen der
Formelgruppen auszuführen sind. Dazu dient der Hinweis für Berechnung.
 Hinweis
Wenn Sie den symmetrischen Rechenmodus eingeschaltet haben, können Sie in den Eigenschaften der
Querybestandteile für jeden eingabebereiten Operanden einschließlich der sie verwendenden
Planungskonzepte
eingabebereiten Formeln die Formelpriorität festlegen. Im Feld Hinweis für Berechnung können Sie
zusätzlich festlegen, mit welcher Priorität die Formelgruppe bezogen auf andere Formelgruppen berechnet
werden soll.
1.9.5 Inverse Formel zur Laufzeit
Verwendung
Im folgenden werden die Laufzeitaspekte inverser Formeln erläutert. Wir setzen voraus, dass Sie
eingabebereite und inverse Formeln in der Query-Definition anlegen können.
 Hinweis
Beispiele, die die Laufzeitaspekte inverser Formeln verdeutlichen, finden Sie unter Beispiele: Inverse Formel
zur Laufzeit [Seite 148] sowie im SAP-Hinweis 1236347 .
Eingabebereitschaft von Formeln
Formeln erben ihre Eingabebereitschaft von ihren Operanden: Wenn Sie in der Query-Definition eine
eingabebereite Formel F = F(op1, …, opn) definiert haben, prüft das System zur Laufzeit, ob mindestens ein
Operand eingabebereit ist. Wenn das nicht der Fall ist, ist auch die Formel F nicht eingabebereit. Falls ein
Operand opi = G ebenfalls eine eingabebereite Formel ist, gilt dieselbe Regel für G.
Wie bei eingabebereiten Strukturelementen kann auch die Eingabebereitschaft von Formeln erfordern, dass
bestimmte Merkmale eindeutig bestimmt sind: Wenn eine eingabebereite Formel oder ein Operand einer
solchen Formel Ausnahmeaggregation verwendet, müssen alle Bezugsmerkmale für die Ausnahmeaggregation
auf Zellebene eindeutig bestimmt sein, damit die Formel eingabebereit ist. Dieselbe Regel gilt auch für Werte
von Stammdatenattributen in eingabebereiten Formeln (Formelvariablen vom Typ Ersetzungspfad, bei denen
die Variable durch den Attributwert eines Merkmals ersetzt wird).
Reihenfolge der Berechnungen
Die Berechnung inverser Formeln kann man als eine Art "Umkehrung" des Reportings betrachten. Da die
Planung eingabebereite Queries für die manuelle Planung verwendet, berechnet das System die Reporting-
Formeln für das Resultset, das an das Frontend geschickt wird. In ABAP-Dynpro-Terminologie werden
Reporting-Formeln also im PBO (process before output) berechnet. Nachdem Daten in eingabebereiten Zellen
der Query manuell geändert wurden, wird ein Server-Roundtrip angestoßen, ein sogenannter PAI (process after
input). Zu diesem Zeitpunkt werden inverse Formeln berechnet. Änderungen in eingabebereiten Formeln
werden auf die Basiskennzahlen zurückgeführt, wobei ggf. auch Disaggregationseinstellungen berücksichtigt
werden. Dadurch entstehen neue Deltasätze, die im Deltabuffer abgelegt werden. Im nächsten PBO liest der
OLAP-Prozessor die Deltasätze aus, um seinen internen Zustand und das Resultset aufzufrischen. Dabei
werden die Reporting-Formeln erneut berechnet.
Für die inversen Formeln ergibt sich daraus, dass diese tatsächliche Umkehrungen der eingabebereiten
Formeln im mathematischen Sinne sein müssen. Andernfalls würde eine Änderung in einer eingabebereiten
Formel nach einem vollendeten PAI-PBO-Zyklus im nächsten PBO überschrieben.
Der folgende Abschnitt erläutert die allgemeinen Regeln des implementierten Rechenmodells im einzelnen.
Allgemeine Regeln
Planungskonzepte
Der folgende Abschnitt erläutert die allgemeinen Regeln des implementierten initialen Rechenmodells sowie
des symmetrischen Rechenmodells, das als erweiterter Rechenmodus in der Query-Definition ausgewählt
werden kann.
Abhängig davon, welcher Rechenmodus in der Query-Definition gewählt wurde, stößt das System die
Berechnung von inversen Formeln entweder nur dann an, wenn eingabebereite Formeln geändert wurden bzw.
wenn diese fixiert waren und andere Operanden von eingabebereiten Formeln geändert wurden (initialer oder
asymmetrischer Rechenmodus), oder aber, wenn irgendein Element einer Formelgruppe manuell geändert
oder fixiert wurde (symmetrischer Rechenmodus).
Angenommen F = F(op1,..., opn) ist eine eingabebereite Formel, wobei die Operanden op1,..., opk mit k < n
ebenfalls eingabebereit sind. In der Query-Definition wurden dann k inverse Formeln angelegt, um die
Operanden op1,..., opn zu berechnen:
Fi = Fi(F, op1,…, opi-1, opi+1, … , opk, … , opn) für i = 1,…, k
Wenn z.B. F geändert wurde, muss das System die 'beste' inverse Formel Fi für deren Berechnung finden. Das
Ergebnis von Fi wird an opi weitergegeben. Dann kann der neue Wert von opi weitere Berechnungen oder eine
Disaggregation anstoßen.
Die folgenden Regeln wendet das System für die Formelinversion an:
1. Formelinversionen werden auf der Grundlage von Datensätzen durchgeführt. Hier bestimmen die Werte
der Merkmale im Aufriss den Datensatz. Die Berechnung der inversen Formeln findet pro Datensatz für die
in der Query-Definition definierten Strukturbestandteile statt; diese Berechnungen werden von anderen
Datensätzen nicht beeinflusst.
2. Eingabebereite Formeln werden auf eingabebereite Basis- oder eingeschränkte Kennzahlen
zurückgerechnet, ggf. durch Inversion anderer eingabebereiter Formeln, wenn es ineinander geschachtelte
Formelgruppen gibt. Diese Änderungen stoßen eine Disaggregation an, sofern Kennzahlen eine der
Disaggregationseinstellungen verwenden.
3. In einem Server-Roundtrip wird pro Formelgruppe nur eine inverse Formel gerechnet. Nach dieser
Berechnung sind alle Elemente dieser Formelgruppe temporär fixiert, d.h. während dieses Server-
Roundtrips können die Elemente einer bereits berechneten Formelgruppe nicht durch Berechnungen aus
anderen Formelgruppen überschrieben werden.
4. Um diejenige inverse Formel herauszufinden, die berechnet werden muss, sammelt das System zuerst die
Elemente, die Berechnungen auslösen, d.h. geänderte oder fixierte Zellwerte von eingabebereiten Formeln
oder Elementen einer Formelgruppe (für jeden Datensatz). Je nach Rechenmodus (asymmetrisch oder
symmetrisch) ist es unterschiedlich, welche Elemente die Berechnung auslösen. Wenn ein Operand der
Formelgruppe in einem früheren Schritt berechnet wurde, wird auch dieser Operand als fix für die neue
Berechnung behandelt, d.h. er wird als eine bekannte Quelle betrachtet. Mögliche Ziele für die Berechnung
sind die eingabebereiten Operanden der aktuellen Formelgruppe, die nicht geändert, fixiert oder berechnet
wurden. Falls daraus nicht eindeutig eine der inversen Formeln als zu berechnen hervorgeht, nimmt das
System die inverse Formel mit der (in der Query-Definition festgelegten) höchsten Formelpriorität.
5. An den durch manuelle Änderungen oder fixierte Zellwerte ausgelösten Berechnungen können mehrere
Formelgruppen beteiligt sein. Da sich die Festlegung der Formelpriorität auf alle Elemente einer
Formelgruppe bezieht, ist nicht eindeutig bestimmt, welche Formelgruppe als erste zu berechnen ist. Das
System berechnet die Formelgruppen in aufsteigender Reihenfolge nach der Anzahl der "Freiheitsgrade".
Der aktuelle Freiheitsgrad wird durch die Differenz von Anzahl der Operanden minus der Anzahl von bereits
bekannten Operanden (d.h. Konstanten, fixierte, manuell geänderte oder in einem früheren Schritt
berechnete Operanden) festgelegt. Falls sogar der aktuelle Freiheitsgrad der Formelgruppen derselbe ist,
prüft das System, ob der symmetrische Rechenmodus verwendet wird. Falls dies der Fall ist, wertet das
Planungskonzepte
System den Hinweis zur Berechnung aus, um die Formelgruppenpriorität zu klären. In allen anderen Fällen
ist die Reihenfolge der Berechnung undefiniert.
6. In Hinsicht auf die Formelinversion werden neue Zeilen wie bestehende behandelt. Wenn es die Zeile
bereits gibt, werden geänderte oder zurückgerechnete Werte von Basis-Kennzahlen aggregiert.
 Hinweis
Beachten Sie, dass das System nicht versucht, irgendeine Lösung für das Rechenproblem zu finden,
welches aufgrund manueller Eingaben und aller Arten von Customizing eingabebereiter Queries entsteht.
Das System wendet zur Lösungsfindung die oben genannten Regeln an. Wenn dies nicht zum Erfolg führt,
weist das System mit entsprechenden Fehlermeldungen darauf hin.
Fehlerbehandlung
Wenn das System keine inverse Formel zur Berechnung findet, ist die Benutzereingabe ungültig. Das System
generiert Meldungen, die auf die Ursachen des Problems - wie z.B. zu viele manuelle Änderungen oder zu viele
Einschränkungen aufgrund fixierter Werte - hinweisen.
Es gibt Fälle, in denen sämtliche Formelinversionen möglich sind, aber nicht die anschließende Disaggregation
der Werte, wenn z.B. sämtliche Einzelwerte einer Teilsumme, einer Gesamtsumme oder eines
Hierarchieknotens und die Teilsumme, Gesamtsumme oder der Hierarchieknoten selbst geändert oder
berechnet wurden. Das System generiert entsprechende Meldungen.
Rundungsregeln
Kennzahlwerte werden in der Datenbank mit einer begrenzten Anzahl von Dezimalstellen gespeichert. Bei der
Berechnung von Formeln treten im allgemeinen Rundungseffekte auf. Durch inverse Formeln können
Kennzahlwerte berechnet werden, die auf der Datenbank abgelegt werden. Für solche Kennzahlen wird daher
jeder berechnete oder durch Disaggregation entstandene Kennzahlwert auf die Datenbank-Dezimalen
gerundet. Wenn das System aggregierte Werte durch inverse Formeln berechnet und die berechneten Werte
disaggregiert, können Rundungsfehler erheblich werden. Beachten Sie daher, dass ein Wert, der manuell
geändert wurde, nach der Berechnung der Formelinversion und der Aktualisierung des Result-Sets von dem
eingegebenen Wert abweichen kann. Dasselbe gilt auch für fixierte Werte.
 Empfehlung
Wir empfehlen daher, für alle Operanden von inversen Formeln dieselbe Anzahl von
Datenbankdezimalstellen zu verwenden.
Empfehlungen
Wir empfehlen, ineinander geschachtelte eingabebereite Formeln zu vermeiden. Modellieren Sie

eingabebereite Formeln und Formelinversionen möglichst so, dass es nicht zu viele Varianten für mögliche
Berechnungen gibt. Die zur Laufzeit ausgeführten Berechnungen sind dann leichter zu verstehen.
Um bei Quotienten als eingabebereiten Formeln, z.B. bei dem Durchschnittspreis, formale Divisionsfehler wie
Division durch Null zu vermeiden, verwenden Sie den Operator NDIV0. Wenn z.B. noch keine Daten geplant
sind und für einige Merkmale unter Zugriffsart für Ergebniswerte die Einstellung Stammdaten oder
Merkmalsbeziehungen verwendet wird, entstehen im allgemeinen viele leere Datenzellen. Ohne die Nutzung
der Datenfunktion NDIV0 wären dann die Zellen für Durchschnittspreis nicht eingabebereit. Wenn Sie jedoch
NDIV0 verwenden, ergibt die Berechnung NDIV0( 0 / 0 ) = 0 für solche Zellen und der Durchschnittspreis kann
geändert werden.
Planungskonzepte

Eingabebereite Queries zur Ausführungszeit [Seite 122]
Inverse Formel definieren [Seite 135]
Diese Links führen in die Dokumentation des Konzeptes der eingabebereiten Query.
1.9.5.1 Prozentfunktionen zur Laufzeit
Prozentfunktion %GT (Prozentualer Anteil an der Gesamtsumme)
Allgemeine Regeln für die Prozentfunktion %GT zur Laufzeit
Zur Laufzeit kann eine eingabebereite Formel mit der Prozentfunktion %GT(op), Prozentualer Anteil an der
Gesamtsumme, nur dann wirklich eingabebereit sein, wenn der Operand op zur Laufzeit eingabebereit ist.
 Hinweis
Weitere Informationen über allgemeine Regeln, wie die Eigenschaft "nicht eingabebereit" für Teilsummen,
Summen und Hierarchieknoten vererbt wird, finden Sie im SAP-Hinweis 994853 .
 Beispiel
Ausführliche Erläuterungen der geltenden Regeln finden Sie in der Diskussion des Beispieles 6,
Prozentualer Anteil %GT, im Abschnitt Beispiele: Inverse Formel zur Laufzeit [Seite 148].
Berechnung der Prozentfunktion %GT in neuen Zeilen
Das System führt Berechnungen inverser Formeln auch in neuen Zeilen durch. Dies führt zu geänderten Werten
der Basis-Kennzahlen. Falls Zeilen bereits vorhanden waren, addiert das System die geänderten Werte auf die
bestehenden Werte. Es gibt keine speziellen Prüfungen für neue Zeilen.
Prozentfunktionen %XT (Normieren auf Ergebnis entlang der Spalten), %YT

(Normieren auf Ergebnis entlang der Zeilen)
Allgemeine Regeln für die Prozentfunktionen %XT, %YT zur Laufzeit
Die Funktionen %XT, %YT können in denselben Clients verwendet werden wie %GT. %XT(op), %YT(op) sind
nur eingabebereit, wenn der Operand op eingabebereit ist.
Planungskonzepte
Die Funktion %XT bzw. %YT berechnet die Prozentwerte bezogen auf die nächste Summenstufe der X- bzw.
der Y- Achse.
 Hinweis
Falls eine SAP BW∕4HANA-Hierarchie auf der X- oder Y-Achse verwendet wird, berechnet die Formel den
Prozentwert des Operanden mit Rücksicht auf den Wurzelknoten der Hierarchie und nicht mit Rücksicht
auf den nächsten Vaterknoten der Hierarchie.
In den folgenden Fällen nimmt das System die Eingabebereitschaft der Prozentfunktionen %XT und %YT
zurück:
● Es wird eine Hierarchie in der jeweiligs betroffenen Achse verwendet, d.h. es wird %XT verwendet und
gleichzeitig eine Hierarchie auf der X-Achse bzw. es wird %YT verwendet und eine Hierarchie auf der Y-
Achse.
● Es werden Teilsummen in der Ergebnismenge der Queries unterdrückt, die für die Berechnung der
Prozentfunktionen jedoch notwendig sind.
Wenn der Wert der Zelle %XT(op) geändert wird, übernimmt das System den geänderten Prozentwert und
berechnet den neuen Wert von op auf der Grundlage des nächsten Summenstufenwertes von op auf der X-
Achse. Außerdem fixiert das System den Wert der Zwischensumme, um sicherzustellen, dass der geänderte
Protzentwert nach einem Serverroundtrip bewahrt bleibt. Entsprechend führt das System auch die
Berechnungen für geänderte %YT-Werte durch.
Berechnung der Prozentfunktionen %XT, %YT in neuen Zeilen
In neuen Zeilen sind die Funktionen %XT, %YT nicht eingabebereit. Es hängt vom Client ab, ob die
entsprechenden Zellen als nicht eingabebereit dargestellt werden.
1.9.5.2 Beispiele: Inverse Formel zur Laufzeit
Verwendung
Im folgenden werden die Laufzeitaspekte inverser Formeln an Hand ausgewählter Beispiele erläutert.
Beispiel 1: Durchschnittspreis
Wie in der Dokumentation zur Definition inverser Formeln beginnen wir mit dem Beispiel Durchschnittspreis.
Wir nehmen an, dass Umsatz (Sales) und Menge (Sales Quantity) eingeschränkte Kennzahlen sind (wobei für
Umsatz die Währung auf einen Wert eingeschränkt und eine initiale Mengeneinheit festgelegt ist und für Menge
umgekehrt). Beide eingeschränkte Kennzahlen verwenden in der Query-Definition unter Planung auf Summen
die Einstellung Eingegebenen Wert disaggregieren.
Eine Datenscheibe schützt die Produkte Comes after C++ und MMIX by D.E. Knuth.
Wie das folgende Bild zeigt, ist die Summenzeile Werkzeuge (Tools) nicht eingabebereit, weder für die
eingeschränkten Kennzahlen Menge und Umsatz noch für die (eingabebereite) Formel Durchschnittspreis (Avg.
Price). Die Formel Durchschnittspreis ist hier nicht eingabebereit, da alle Operanden dieser Formel nicht
eingabebereit sind.
Planungskonzepte
Query-Beispiel Durchschnittspreis
Beispiel 2: Durch manuelle Änderungen angestoßene Formelinversion
Wir verdeutlichen die allgemeinen Regeln am Beispiel der berechneten eingabebereiten Kennzahl
Durchschnittspreis (siehe oben Beispiel 1).
Wir nehmen an, dass der initiale (asymmetrische) Rechenmodus Anwendung findet.
Hier ist der Durchschnittspreis Träger der Formelgruppe, die aus folgenden Elementen besteht:
Durchschnittspreis, Umsatz und Menge. In der Query-Definition sind die folgenden beiden inversen Formeln
definiert worden:
1. 'Umsatz' = 'Durchschnittspreis' * 'Menge'

2. 'Menge' = NDIV0('Umsatz' / 'Durchschnittspreis')
● Wir nehmen an, dass der Wert für den Durchschnittspreis geändert wurde. Beide inverse Formeln können
für die Formelinversion verwendet werden; das System nimmt die Formel mit der höchsten Formelpriorität,
in diesem Falle die Umsatz-Formel.
● Wir nehmen an, dass die Werte für den Durchschnittspreis und den Umsatz geändert wurden. In diesem Fall
ist es eindeutig, dass das System die Menge-Formel berechnen muss.
● Wir nehmen an, dass der Wert für den Durchschnittspreis geändert und die Zelle Umsatz fixiert wurde. In
diesem Fall ist es eindeutig, dass das System die Menge-Formel berechnen muss.
Planungskonzepte
● Wir nehmen an, dass der Wert für den Durchschnittspreis geändert wurde und die Zelle Umsatz nicht
eingabebereit ist, z.B. weil diese Kennzahl durch eine Datenscheibe geschützt ist. In diesem Fall ist es
eindeutig, dass das System die Menge-Formel berechnen muss.
● Wir nehmen an, dass die Werte für den Umsatz oder Menge geändert wurden. Dann spielen inverse
Formeln keine Rolle. Das System berechnet den Durchschnittspreis.
● Wir nehmen an, dass der Wert für den Umsatz geändert und die Zelle Durchschnittspreis fixiert. In diesem
Fall ist es eindeutig, dass das System die Umsatz-Formel berechnen muss.
Wir nehmen an, dass der symmetrische Rechenmodus Anwendung findet.
Hier ist der Durchschnittspreis Träger der Formelgruppe, die aus folgenden Elementen besteht:
Durchschnittspreis, Umsatz und Menge. In der Query-Definition sind die folgenden beiden inversen Formeln
definiert worden; zusätzlich hat die Trägerformel die niedrigste Priorität:
1. 'Umsatz' = 'Durchschnittspreis' * 'Menge'

2. 'Menge' = NDIV0('Umsatz' / 'Durchschnittspreis')
3. 'Durchschnittspreis' (Trägerformel)
● Wir nehmen an, dass der Wert für den Durchschnittspreis geändert wurde. Beide inverse Formeln können
für die Formelinversion verwendet werden; das System nimmt die Formel mit der höchsten Formelpriorität,
in diesem Falle die Umsatz-Formel.
● Wir nehmen an, dass die Werte für den Durchschnittspreis und den Umsatz geändert wurden. In diesem Fall
ist es eindeutig, dass das System die Menge-Formel berechnen muss.
● Wir nehmen an, dass der Wert für den Durchschnittspreis geändert wurde und die Zelle Umsatz nicht
eingabebereit ist, z.B. weil diese Kennzahl durch eine Datenscheibe geschützt ist. In diesem Fall ist es
eindeutig, dass das System die Menge-Formel berechnen muss.
● Wir nehmen an, dass die Werte für den Umsatz geändert wurden. Damit wird die Berechnung der
Formelgruppe angestoßen. Weil Menge eine höhere Priorität hat, wird Durchschnittspreis beibehalten und
auf Menge zurückgerechnet.
● Wir nehmen an, dass die Werte für den Menge geändert wurden. Damit wird die Berechnung der
Formelgruppe angestoßen. Weil Umsatz die höchste Priorität hat, wird Durchschnittspreis beibehalten
und auf Umsatz zurückgerechnet.
● Wir nehmen an, dass der Wert für den Umsatz geändert und die Zelle Durchschnittspreis fixiert. In diesem
Fall ist es eindeutig, dass das System die Umsatz-Formel berechnen muss.
Beispiel 3: Sich überlappende Formelgruppen
In diesem Beispiel nutzen wir drei eingeschränkte Kennzahlen: Umsatz geplant, Umsatz Prognose, Umsatz
aktuell. Wir möchten auch die prozentuale Abweichung des geplanten vom vorausberechneten sowie des
geplanten vom aktuellen Umsatz planen. Daher legen wir zwei eingabebereite Formeln und die entsprechenden
inversen Formeln an.
Die eingabebereite Formel zur Berechnung der prozentuale Abweichung des geplanten vom aktuellen Umsatz
lautet:
%Dev (P,A) = NDIV0( 'Umsatz geplant' % 'Umsatz aktuell' )
Diese Formelgruppe hat als Elemente: '%Dev(P,A)', Umsatz geplant und Umsatz aktuell.
Planungskonzepte
Die eingabebereite Formel zur Berechnung der prozentuale Abweichung des geplanten vom prognostizierten
Umsatz lautet:
%Dev (P,F) = NDIV0( 'Umsatz geplant' % 'Umsatz Prognose' )
Diese Formelgruppe hat als Elemente: '%Dev(P,F)', Umsatz geplant und Umsatz Prognose.
Beide Formelgruppen enthalten das Element Umsatz geplant. Wir nehmen an, dass Umsatz aktuell und Umsatz
Prognose nicht eingabebereit sind, z.B. weil die Vorausberechnung vom Planungsadministrator vorbereitet
wurde. In diesem Fall sind eingabebereit: Umsatz geplant, '%Dev(P,A)' und '%Dev(P,F)'. Das System braucht
nur Inversionen von '%Dev(P,A)' auf Umsatz geplant und von '%Dev(P,F)' auf Umsatz geplant.
Produkt %Dev (P,F) %Dev (P,A) Umsatz geplant Umsatz Prognose Umsatz aktuell
PC Medium 0 10 -> 20 110 110 100
PC Small 0 -> 10 10 220 220 200
PC High End 0 -> 10 10 -> 20 330 Error 330 300
Gesamt 0 10 660 660 600
Die manuelle Eingabe ist in der Tabelle dargestellt durch den Pfeil '->'. Für eine bessere Übersichtlichkeit
enthält diese Tabelle gleich alle drei im folgenden näher erklärten Beispiele. Das soll aber nicht bedeuten, dass
die Änderungen in einem einzigen Interaktionsschritt durchgeführt wurden.
1. Wenn man '%Dev(P,A)' für 'PC Medium' ändert, errechnet das System zuerst im PAI (process after input)
den Umsatz geplant und dann im PBO (process before output) die prozentuale Abweichung '%Dev(P,F)'.
2. Wenn man '%Dev(P,F)' für 'PC Small' ändert, errechnet das System zuerst im PAI den Umsatz geplant und
dann im PBO die prozentuale Abweichung '%Dev(P,A)'.
3. Wenn man '%Dev(P,A)' und '%Dev(P,F)' in einem Schritt für 'PC High End' ändert, versucht das System,
Umsatz geplant zu berechnen. Das ist für eine Formelgruppe möglich, bei der anderen aber versucht das
System, zugleich auch Umsatz geplant abzugleichen. Dieses Verhalten führt zu einem Fehler, da die
anderen Kennzahlen nicht eingabebereit sind und daher nicht über die Berechnung inverser Formeln
geändert werden.
Ohne den unter 3. beschriebenen Fehlerfall erhält man folgendes Ergebnis:
Produkt %Dev (P,F) %Dev (P,A) Umsatz geplant Umsatz Prognose Umsatz aktuell
PC Medium 9.09 20 120 110 100
PC Small 21.00 10 242 220 200
PC High End 0.00 10 330 330 300
Gesamt 4.84 15.34 692 660 600
Beispiel 4: Ineinander geschachtelte Formelgruppen
In diesem Beispiel möchten wir Kosten einiger Kostenstellen planen. Wir nehmen an, wir haben zwei
Kennzahlen Fixe Kosten and Variable Kosten. Fixe Kosten ist nicht eingabebereit, da wir in diesem Beispiel
Planungskonzepte
annehmen, dass wir diese Kosten nicht beeinflussen können. Variable Kosten werden geplant. Die
Gesamtkosten sind die fixen Kosten zuzüglich der variablen Kosten. Vom vergangenen Jahr haben wir bereits
die Gesamtkosten in einer eingeschränkten Kennzahl Kosten LY; hiervon interessieren uns die fixen und die
variablen Kostenanteile nicht. Wir möchten allerdings die prozentuale Abweichung der Gesamtkosten von den
Gesamtkosten des Vorjahres planen. Diese Überlegungen zusammenfassend, können wir zwei eingabebereite
Formeln bilden:
'Gesamtkosten' = 'Variable Kosten' + 'Fixe Kosten'
Diese Formelgruppe hat als Elemente: Gesamtkosten, Variable Kosten und Fixe Kosten.
Die andere eingabebereite Formel ist:
'%Dev(T, LY) = 'Gesamtkosten' % 'Kosten LY'
Diese Formelgruppe hat als Elemente: '%Dev(T,LY)l', Gesamtkosten und Kosten LY.
Die beiden Formelgruppen sind ineinander geschachtelt, da die Formel Gesamtkosten auch in der Formel
'%Dev(T,LY)' verwendet wird.
Kostenstelle %Dev (T,LY) Gesamtkosten Variable Kosten Fixe Kosten Kosten LY
4711 10 110 -> 120 100 10 100
4712 10 -> 20 220 200 20 200
4713 10 -> 20 330 -> 400 300 Error 30 300
Gesamt 10 660 600 60 600
Die manuelle Eingabe ist in der Tabelle dargestellt durch den Pfeil '->'. Für eine bessere Übersichtlichkeit
enthält diese Tabelle gleich alle drei im folgenden näher erklärten Beispiele. Das soll aber nicht bedeuten, dass
die Änderungen in einem einzigen Interaktionsschritt durchgeführt wurden.
1. Wenn man die Gesamtkosten für die Kostenstelle 4711 ändert, errechnet das System zuerst im PAI die
Variablen Kosten und rechnet dann im PBO zurück auf die Gesamtkosten und die prozentuale Abweichung
zum Vorjahr '%Dev(T,LY)'.
2. Wenn man die prozentuale Abweichung zum Vorjahr '%Dev(T,LY)' für die Kostenstelle 4712 ändert,
errechnet das System zuerst im PAI die Gesamtkosten, weil die Formel eingabebereit ist. Diese implizite
Änderung stößt die nächste Formelinversion an. Im Ergebnis berechnet das System auch die Variablen
Kosten im PAI. Im PBO rechnet das System dann zurück auf die Gesamtkosten und auf die prozentuale
Abweichung zum Vorjahr '%Dev(T,LY)'.
3. Wenn man die prozentuale Abweichung zum Vorjahr '%Dev(T,LY)' und die Gesamtkosten für die
Kostenstelle 4713 in einem Schritt ändert, wurde zugleich auch der einzige eingabebereite Operand der
Formel '%Dev(T,LY)' geändert. Damit ist eine Formelinversion für die prozentuale Abweichung zum Vorjahr
'%Dev(T,LY)' nicht möglich. Das System weist mit entsprechenden Fehlermeldungen darauf hin.
Planungskonzepte
Ohne den unter 3. beschriebenen Fehlerfall erhält man folgendes Ergebnis:
Kostenstelle %Dev (T,LY) Gesamtkosten Variable Kosten Fixe Kosten Kosten LY
4711 20 120 110 10 100
4712 20 240 220 20 200
4713 10 330 300 30 300
Gesamt 15 690 630 60 600
Beispiel 5: Berechnung inverser Formeln und Disaggregation
Im folgenden zeigen wir ein noch komplexeres Beispiel, indem wir mehrere Werte auf verschiedenen Ebenen
des Result-Sets in einem Schritt ändern. Wir nehmen an, die folgende Formel hat die höchste Priorität:
'Menge' = NDIV0( 'Umsatz' / 'Durchschnittspreis' )
Wie durch die Pfeile ' -> ' angezeigt, wurden in der folgenden Tabelle einige Zahlen auf verschiedenen
Summationsstufen in einem Schritt geändert. Beachten Sie, dass das System hier zuerst die inversen Formeln
aller Ebenen berechnet und dann geänderte oder berechnete Werte auf die Basiskennzahlen disaggregiert.
Produkt Umsatz Menge Durchschnittspreis
PC Medium 4000.00 3 1333.33 -> 800
PC Small 4000.00 4 -> 3 1000.00 -> 500
PC High End 4000.00 3 1333.33
Gesamt 12000.00 10 1200.00 -> 1000
Diese Änderungen stoßen die folgenden Berechnungen an:
PC Medium 4000.00 (zeitweilig fixiert) 4000.00 / 800 (Priorität) 1333.33 -> 800
PC Small 3 * 500 4 -> 3 1000.00 -> 500
PC High End 4000.00 3 1333.33
Gesamt 12000.00 (zeitweilig fixiert) 12000.00 / 1000 (Priorität) 1200.00 -> 1000
Planungskonzepte
Das Zwischenergebnis ist folgendes:
PC Medium 4000.00 (zeitweilig fixiert) 5 (berechnet) 800 (geändert)
PC Small 1500 (berechnet) 3 (geändert) 500 (geändert)
PC High End 4000.00 3 1333.33
Gesamt 12000.00 (zeitweilig fixiert) 12 (berechnet) 1000 (geändert)
Die Mengen-Spalte enthält einen geänderten Gesamt-Wert und Änderungen von Werten auf niedrigeren
Ebenen. Das System beginnt daher die Disaggregation von 12 - ( 5 + 3 ) = 4 für den einzigen unveränderten
Wert des Produktes 'PC High End'.
Die Umsatz-Spalte enthält (durch Berechnungen in den jeweiligen Zeilen) zeitweilig fixierte Werte und einen
geänderten Wert. Das System beginnt daher die Disaggregation von 12000 - ( 4000 + 1500 ) = 6500 für den
einzigen unveränderten Wert des Produktes 'PC High End'.
Das Ergebnis der Berechnung der inversen Formeln und der Disaggregation ist folgendes:
Product Umsatz Menge Durchschnittspreis
PC Medium 4000.00 5 800.00
PC Small 1500.00 3 500.00
PC High End 6500.00 4 1625.00
Total 12000.00 12 1000.00
Beispiel 6: Prozentualer Anteil %GT
Wir erläutern die Laufzeitaspekte des Beispiels Prozentualer Anteil %GT (siehe Beispiele: Inverse Formel [Seite
142], Beispiel 2).
Wir nehmen an, dass der Betrag eine Basis-Kennzahl mit der Verteilungsart für Disaggregation
Analogverteilung (zu sich selbst) ist.
Eine Datenscheibe schützt die Produkte Comes after C++ und MMIX by D.E. Knuth.
Wie das folgende Bild zeigt, ist die Summe der Spalte Prozentualer Anteil des Betrages in Hinsicht auf die
Gesamtsumme ( % Contribution) nicht eingabebereit, da der entsprechende Wert immer 100% ist. Alle
übrigen Zellen sind eingabebereit mit Ausnahme der Werte für die Produkte Comes after C++ und MMIX by D.E.
Knuth und die Teilsummen für diese Produkte. Die Basis-Kennzahl Betrag ( Amount) wird durch eine
Datenscheibe geschützt. Im Ergebnis ist auch die Eingabebereitschaft für Prozentualer Anteil ( % Contribution)
ausgeschaltet: Die Eigenschaft "nicht eingabebereit" wurde durch die Formel %GT von dem Operanden Betrag
( Amount) geerbt. Zusätzlich wurde die Eigenschaft "nicht eingabebereit" von der Teilsumme Tools geerbt, da
alle Kinder dieses Hierarchieknotens nicht eingabebereit sind.
Planungskonzepte
Der Wert von %GT für die Gesamtsumme ist immer 100%; daher ist das Gesamtergebnis nicht eingabebereit.
So bleibt der Wert für %GT auch 100%, wenn man z.B. einen Filter (auf der Achse) für Personal Computer
verwendet. Berechnungen mit %GT sind noch möglich, wenn keine Teilsummen, Summen oder
Hierarchieknoten angezeigt werden. Es ist auch möglich, die Kennzahl op, in unserem Beispiel Betrag
( Amount), auszublenden; der Operand op, hier Betrag ( Amount), muss dann aber eingabebereit sein.
Wenn beide, sowohl der Operand op, in unserem Beispiel Betrag ( Amount), als auch %GT für dieselbe Ebene in
einem einzigen Interaktionsschritt geändert werden, weist das System darauf mit Fehlermeldungen hin.
Möglich ist hingegen, das Gesamtergebnis für op, d.h. Betrag ( Amount), und die Werte für %GT auf einer
tieferen Ebene zu ändern. In diesem Fall nimmt das System den neuen Wert für das Gesamtergebnis und den
geänderten Wert %GT, um den neuen Wert für den Operanden op, d.h. Betrag ( Amount), auf der tieferen Ebene
zu berechnen. Diese beiden Änderungen stoßen eine Disaggregation für den Operanden op, d.h. Betrag
( Amount), an.
Das Gesamtergebnis für Betrag ( Amount) darf nicht gleich Null sein. Falls das nicht der Fall ist, sind %GT-Zellen
nicht eingabebereit.
Werte für %GT können auch außerhalb des Bereichs von 0 bis 100 liegen; im allgemeinen wird dies - nach
Disaggregation - zu negativen Werten für den Operanden, d.h. Betrag ( Amount), führen.
Planungskonzepte
1.9.6 Stammdatenplanung
Sie können ein InfoObject (Merkmal) mit Stammdatentabelle als Basis-InfoProvider für die
Stammdatenplanung verwenden, indem alle Attribute und Texte dieses InfoObject zusätzlich als beplanbare
Kennzahlen exponiert werden.
Voraussetzungen
● InfoObject (Merkmal):
Als für die Stammdatenplanung geeigneten Basis-InfoProvider haben Sie ein InfoObject (Merkmal) mit
Stammdatentabelle mit Mitteln des SAP BW∕4HANA und ohne die Eigenschaft Erweiterte
Stammfortschreibung angelegt.
Um die Stammdatenplanung zu ermöglichen, haben Sie diesem InfoObject (Merkmal) die
Modellierungseigenschaften Usable as InfoProvider und Planning Mode zugewiesen und es vom Load Mode
in den Planning Mode umgeschaltet.
● Aggregationsebene:
Auf diesem Basis-InfoProvider haben Sie eine Aggregationsebene anlegt. Das System hat als Metadaten
für Attribute und Texte des InfoProviders Kennzahlen erzeugt.
● Query:
Auf dieser Aggregationsebene haben Sie eingabebereite Queries angelegt.
 Hinweis
Alle Schlüsselmerkmale, Attribute und Texte, die beplanbar sein sollen, müssen eingabebereit sein.
Setzen Sie dazu in den Eigenschaften des Strukturelementes auf der Registerkarte Planning in dem
Feld Input-Ready den Wert Yes.
Optional können Sie als Disaggregationsverhalten wählen: Disaggregation Kopieren, homogene Werte.
Besonderheiten bei der Planung auf Stammdaten
Wenn Sie die Query im Änderungsmodus starten, können Sie Stammdaten ändern. Alle Attribute und Texte des
InfoObjects, die in der Aggregationsebene enthalten sind, können als Kennzahlen in der Query verwendet
werden.
Wenn es zeitabhängige Attribute und Texte gibt, können Sie zusätzlich die folgenden Kennzahlenin die
Aggregationsebene aufnehmen und in der Query verwenden:
● Attribute: 1KYF_1DATEFROM, 1KYF_1DATETO

● Texte: 1KYF_1TXTDATEFROM, 1KYF_1TXTDATETO
Diese Kennzahlen können eingabebereit sein oder nicht, je nachdem ob diese Felder änderbar sein sollen oder
nicht. Falls sie änderbar sein sollen, gilt, dass die neuen Grenzen des Zeitintervalls innerhalb desjenigen
Zeitintervalls liegen müssen, in dem der Query-Stichtag liegt. Dazu kommt, dass die untere Grenze des
Zeitintervalls unter (oder gleich) dem Query-Stichtag sein muss, die obere Grenze über (oder gleich) dem
Query-Stichtag. Der Query-Stichtag selbst kann fest oder variabel sein. Es gilt also:
Planungskonzepte
● Attribute: DATEFROM(alt) < DATEFROM(neu) <= KEY_DATE(Query-Stichtag) <= DATETO(neu) < DATETO(alt)
● Texte: TXTDATEFROM(alt) < TXTDATEFROM(neu) <= KEY_DATE(Query-Stichtag) <= TXTDATETO(neu) <
TXTDATETO(alt)
Neue Zeilen: Ein InfoObject-Wert in einer neuen Zeile ist ein neuer Stammdatenwert. Wenn die Felder
DATEFROM und DATETO nicht als Kennzahlen in der Query verwendet werden oder nicht eingabebereit sind,
setzt das System die folgenden Werte:
● *DATEFROM = 01.01.1000
● *DATEFTO = 31.12.9999
 Hinweis
Sichern der Stammdatenänderungen: Beachten Sie, dass alle Änderungen an Stammdaten, Attributen
und Texten in einen einzigen Auftrag gelangen.
Sperrkonzept: Relevant für Sperren sind nur die Schlüsselmerkmale. Attribute sind nicht relevant für
Sperren.

1.10 Sichern geänderter Werte
Wenn Sie Ihre Daten in einer Planungsanwendung sichern, persistiert das System die seit dem letzten Sichern
veränderten Daten auf der Datenbank. Sie können die Daten vor dem Sichern mit einer Planungssequenz
prüfen. Um die gesicherten Werte zu protokollieren, implementieren Sie das Interface
IF_RSPLS_LOGGING_ON_SAVE.
Verwendung
Wenn Sie Ihre Daten in einer Planungsanwendung sichern, persistiert das System die seit dem letzten Sichern
veränderten Daten auf der Datenbank. Dabei werden immer die Änderungen an Daten (und nicht die absoluten
Werte) gebucht.
Daten vor dem Sichern mit einer Planungssequenz prüfen
Um zu vermeiden, dass Benutzer einer Planungsanwendung geänderte Daten sichern, die als ungültig gelten,
können Sie als Administrator festlegen, dass bei jedem Sichern-Ereignis zu einem InfoProvider eine bestimmte
Planungssequenz ausgeführt wird, die die Daten dieses InfoProviders prüft.
Planungskonzepte
Gesicherte Werte protokollieren
Mit dem BAdI BADI_RSPLS_LOGGING_ON_SAVE des Erweiterungsspots RSPLS_LOGGING_ON_SAVE können

Sie diejenigen Daten protokollieren, die im Rahmen einer Planungsanwendung gesichert werden. Diese
Protokollierung kann bei für die Planung geeigneten Basis-InfoProvidern implementiert werden.
Das BAdI ist filterabhängig. Legen Sie für jeden geeigneten Basis-InfoProvider, für den Sie eine Protokollierung
vornehmen möchten, eine Implementierung des Interfaces IF_RSPLS_LOGGING_ON_SAVE an.
Das BAdI wird gerufen, wenn Daten im Rahmen einer Planungsanwendung in einen geeigneten Basis-
InfoProvider gesichert werden, nicht aber, wenn der InfoProvider anderweitig beschrieben wird, z.B. im
Lademodus mit Mitteln des Data Warehouse Management. Sofern Daten des InfoProviders teilweise oder
vollständig gelöscht werden, hat dies keine Auswirkungen auf bereits vorliegende Protokollierungen.
Verwendung der Methoden
● Über die Methoden log_defined bzw. log_structure wird festgelegt, ob bzw. in welchem Format die Daten
zur Verfügung gestellt werden sollen. In der Methode log_structure können Sie festlegen, dass über
spezielle InfoObjects in der DDIC-Struktur auch Kontextinformationen über den Namen des schreibenden
Benutzers, das Datum, die Uhrzeit und die SAVE-ID zur Verfügung stehen. Über die SAVE-ID ist es möglich,
eine Sichern-Aktion in einer Planungsanwendung zu identifizieren.
 Beispiel
Wenn also z.B. ein Benutzer im Rahmen einer Planungsanwendung insgesamt dreimal Daten sichert
und jeweils zwei Basis-InfoProvider beschreibt und zudem für beide Basis-InfoProvider die
Protokollierung aktiv ist, so werden insgesamt drei SAVE-IDs vom System erzeugt, die jeweils den
beiden Protokollierungsaufrufen der beiden Basis-InfoProvider bei Bedarf mitgegeben werden. Es ist
somit möglich, in den Protokollen der beiden Basis-InfoProvider zu identifizieren, welche Daten aus
Basis-InfoProvider1 zusammen mit welchen Daten aus Basis-InfoProvider2 gesichert wurden.
● Mit der Methode log_write wird die eigentliche Protokollierung bei jedem Sichern-Ereignis in der
Anwendung aufgerufen, die die Daten in der über log_structure festgelegten Struktur übergibt. In der
Methode log_write wird die eigentliche Protokollierung implementiert, z.B. das Schreiben der Daten in eine
transparente Tabelle. Der Methode log_write wird neben den Daten auch die Request-ID des geeigneten
InfoProviders mitgeteilt, in der die Daten gesichert wurden.
● Mit der Methode log_defined_db aktivieren Sie das Logging auf der SAP HANA-Datenbank für einen
InfoProvider, den Sie über die Methode log_defined für das Logging klassifiziert haben. Sobald dies erfolgt
ist, wird für den betreffenden InfoProvider die Methode log_write nicht mehr gerufen, sondern die im
folgenden erklärte Methode log_write_db.
● Mit der Methode log_write_db erhalten Sie den Namen einer Datenbanktabelle, die die Struktur
i_structure_name hat und die zu loggenden Daten enthält. Anders als im Falle der Methode log_write
handelt es sich hierbei jedoch nicht um eine interne Tabelle, sondern um eine Datenbanktabelle. Sie ist im
DDIC nicht bekannt und muss daher mit Datenbankmitteln (z.B. ADBC API oder EXEC SQL, also Native
SQL) verarbeitet werden. Indem Sie den Inhalt der jeweiligen Datenbanktabelle in eine Ablage Ihrer Wahl
transformieren, können Sie die Log-Informationen in Ihrer Ablage persistieren.
 Hinweis
Die Methoden dieses Interfaces sind im einzelnen in der Interface-Dokumentation beschrieben (siehe Class
Builder, Transaktionscode SE24).
Planungskonzepte
 Hinweis
Die Methoden des Interfaces IF_RSPLS_LOGGING_ON_SAVE sind im einzelnen in der Interface-

Dokumentation beschrieben (siehe Class Builder, Transaktionscode SE24).
Weitere Informationen finden Sie im SAP-Hinweis 1802658 .
Daten vor dem Sichern mit einer Planungssequenz prüfen

Informationen über die entsprechende Vorgehensweise in den BW-Modellierungswerkzeugen finden Sie im
Abschnitt zu den Zentralen Einstellungen.
Gesicherte Werte protokollieren, Verwendung ohne SAP-HANA-Datenbank
Über die Statistik-Events 50098 und 50099 können Sie die Verarbeitungszeiten messen.
1.11 Audit
Mit Hilfe des Datenaudits können Sie Änderungen an Bewegungsdaten auf der Ebene einer eingabebereiten
Query verfolgen, z. B. wann und von wem Daten in der Query geändert wurden. Der Benutzer kann sich die
Audit-Informationen für jede Zelle der Query in Form von Deltawerten der Änderungshistorie in einer
entsprechenden Audit-Query anschauen.
Unterstützte InfoProvider
Sie können das Datenaudit für folgenden InfoProvider nutzen:
● Data Mart DataStore-Objekt: In einem solchen InfoProvider ist das Datenaudit fest eingebaut und immer
aktiv.
● Lokaler Provider im BW Workspace, wenn dieser für die Planung freigeschaltet ist: Einem solchen lokalen
Provider werden ebenfalls die Audit-Merkmale hinzugefügt.
 Hinweis
Die Audit-Merkmale sollen nur für die Audit-Funktion verwendet werden, also nicht in InfoProvider
aufgenommen werden, die keinen Audit unterstützen.
Planungskonzepte
Verwendung der Audit-Merkmale in den Providern
Data Mart DataStore-Objekt

Voraussetzung ist, dass in einem CompositeProvider, der das DataStore-Objekt enthält, die Eigenschaft zur
Exponierung der Audit-Merkmale (Show Audit Characteristics in Query) gesetzt ist.
Im DataStore-Objekt ist die Audit-Infrastruktur fest eingebaut. Die Audit-Informationen werden über den
Request fortgeschrieben und können in Queries über Navigationsattribute eingebunden werden.
Es werden folgende InfoObjekte verwendet:
● Zeitstempel: 0REQTSN
● User: Navigationsattribut 0REQTSN__0AUSER
● Datenquelle: Navigationsattribut 0REQTSN__ 0ASOURCE
Lokaler Provider im BW Workspace

Wenn Daten über eine eingabebereite Query oder eine Planungsfunktion in einen lokalen Provider geschrieben
werden, füllt das System die Audit-Merkmale wie folgt:
● Datenaudit aktiv:
○ 0ATIMESTAMP = Zeitstempel des Sichern-Ereignisses
○ 0AUSER = SY-UNAME
○ 0AMODE = PLAN
○ 0ASOURCE = Name der Query oder Planungsfunktion, falls eindeutig
● Datenaudit inaktiv:
○ 0ATIMESTAMP = Fester Zeitstempel (Zeitpunkt des Umschaltens von aktiv auf inaktiv)
○ 0AUSER ist leer
○ 0AMODE = OFF
○ 0ASOURCE ist leer
 Achtung
Beachten Sie, dass lokale Objekte und alle Objekte, die einen lokalen Provider referenzieren, nicht
transportierbar sind.
Audit-Merkmale [Seite 160]

Audit-Query [Seite 162]
1.11.1 Audit-Merkmale
Das System verwendet bestimmte Merkmale, um Audit-Informationen zu speichern.
Planungskonzepte
Die Audit-Merkmale werden mit dem Technischen Content des SAP BW∕4HANA ausgeliefert. Sie werden vom
System gefüllt und können vom Benutzer nicht modelliert werden.
Die folgende Tabelle gibt eine Übersicht über die Audit-Merkmale und ihre Werte.
Audit-Merkmale
Merkmal Werte und Beschreibung
0ATIMSTMP Dieses Merkmal enthält den Audit-Zeitstempel.
● Wenn das Datenaudit aktiv ist, enthält dieses Merkmal den Zeitstempel,
wann die Daten auf der Datenbank gesichert wurden.
● Wenn das Datenaudit inaktiv ist, enthält dieses Merkmal den festen Zeit
stempel, wann das Datenaudit von aktiv auf inaktiv umgeschaltet wurde.
0AMODE Dieses Merkmal enthält den Audit-Modus. Zulässige Werte sind die folgenden:
● WHM: Dieser Wert wird im Lademodus verwendet, d.h. wenn die Daten
durch das Laden von Requests in den InfoProvider kommen.
● PLAN: Dieser Wert wird im Planmodus verwendet, d.h. wenn die Daten aus
der Planung kommen.
● OFF: Dieser Wert wird verwendet, wenn das Datenaudit auf inaktiv gesetzt
ist.
0AUSER Dieses Merkmal enthält den Namen des Benutzers, der das Sichern-Ereignis ver
anlasst hat.
● Wenn das Datenaudit aktiv ist, enthält dieses Merkmal den Inhalt des ABAP-
Systemfeldes SY-UNAME.
● Wenn das Datenaudit inaktiv ist, ist dieses Merkmal leer.
0ASOURCE Dieses Merkmal enthält in bestimmten Fällen den Namen der Quelle der Daten
änderung zum Zeitpunkt des Sicherns.
● Wenn das Datenaudit aktiv ist und die Daten aus der Planung kommen
(Planmodus), enthält dieses Merkmal den Name der Query oder der Pla
nungsfunktion, sofern diese eindeutig sind.
 Hinweis
Falls dieses Feld den Namen einer vom System erzeugten Standardqu
ery enthält und dieser Name mit einem ‚!‘ beginnt, wird dieses Zeichen
durch ein ‚$‘-Zeichen ersetzt.
● In allen anderen Fällen ist dieses Merkmal leer.
Audit [Seite 159]
Planungskonzepte
1.11.2 Audit-Query
Das folgende Beispiel zeigt, wie Sie eine eingabebereite Query und eine entsprechende Audit-Query definieren.
Eine Audit-Query können Sie entweder so ausführen, dass Sie die Änderungen nachvollziehen können, oder so,
dass Sie die Deltawerte sehen.
Änderungen in der eingabebereiten Query ZTSC0AC10_Q_INVFORML_01

(ohne und mit Audit)
In dem folgenden Beispiel hat der Benutzer zunächst Werte über die eingabebereite Query in ein Data Mart
DataStore-Objekt geschrieben.
Das folgende Bild zeigt die ausgeführte Query:
Nachfolgend hat der Benutzer in der eingabebereiten Query weitere Änderungen vorgenommen und jeweils
sofort gesichert. Es handelt sich um folgende Änderungen:
1. Für die Zwischensumme Hardware, Personal Computer wurde der Wert von Sales Quantity von 30 auf 60
geändert.
2. Für die Zwischensumme Hardware, Personal Computer wurde der Wert von Sales von 15.000 auf 20.000
geändert.
Planungskonzepte
3. Für die Zwischensumme Hardware, Personal Computer wurde der Wert von Sales Quantity von 60 auf 120
und der Wert von Sales von 20.000 auf 30.000 geändert.
Das folgende Bild zeigt die ausgeführte Query nach den Änderungen:
Definition der Audit-Query ZTSC0H000_Q_AUDIT_00
Die Audit-Query legt man in der Regel auf einen CompositeProvider an, der alle Basis-InfoProvider enthält, die
über eingabebereite Queries oder Planungsfunktionen verändert werden. Wir empfehlen, die Audit-Query
analog zur eingabebereiten Query zu bauen. Zusätzlich sollten jedoch alle Merkmale der Audit-Dimension und
ggf. 0INFOPROV als freie Merkmale verfügbar sein.
In unserem Beispiel wird das Merkmal Request Transaction Sequence Number (0REQTSN) in den Zeilen
aufgerissen. Das Merkmal Product wird aus den Zeilen entfernt, damit man die Änderungen auf der
Zwischensumme einfacher nachvollziehen kann.
Das folgende Bild zeigt die Definition der Audit-Query:
Planungskonzepte
Ausführung der Audit-Query ZTSC0H000_Q_AUDIT_00
Wenn man die Audit-Query ausführt, sieht man das folgende Ergebnis: Man kann über das Merkmal 0REQTSN
nachvollziehen, welche Werte der Benutzer der eingabebereiten Query verändert hat; dazu nutzt man die
Eigenschaft Cumulate Values für das Merkmal 0REQTSN in der Querydefinition.
Das folgende Bild zeigt die ausgeführte Audit-Query mit den Änderungen:
Planungskonzepte
Wenn die Audit-Query ohne die Eigenschaft Cumulate Values für das Merkmal 0REQTSN ausgeführt wird, kann
man die Änderungen (Deltawerte) nachvollziehen.
Das folgende Bild zeigt die ausgeführte Audit-Query mit den Deltawerten:
Planungskonzepte
1.12 Sperrkonzept und Sperrverwaltung
Verwendung
Wenn Bewegungsdaten im Änderungsmodus angefordert werden, müssen diese Daten exklusiv für einen
Benutzer gesperrt werden. Die zu sperrenden Datensätze werden durch eine Selektionstabelle beschrieben.
Ein Datensatz wird genau dann durch die Selektionstabelle gesperrt, wenn für jedes Merkmal der
Selektionstabelle der Merkmalswert im Datensatz in der Selektion liegt. Dabei spielt es keine Rolle, ob dieser
Datensatz auf der Datenbank vorhanden ist.
● Alle Sätze, die in der Selektion liegen, sind gesperrt.

● Wenn die Selektionstabelle leer ist, ist jeder Datensatz gesperrt, da es keine Einschränkungen gibt.
● Für Merkmale außerhalb der Aggregationsebene ist immer die Selektion * (alles) gesperrt.
Planungskonzepte
 Beispiel
Die Selektionstabelle sehe z.B. wie folgt aus:
Merkmal Merkmalswert
Geschäftsjahr 2006
Produkt P1 - P10
Diese Tabelle beschreibt eine Selektion. Alle Sätze, die in diese Selektion fallen, sind gesperrt. Dazu
gehören z.B.:
Geschäftsjahr Produkt
2006 P1 Beide Werte liegen in der Selektion,

d.h. der Satz ist gesperrt.
2006 P20 P20 liegt nicht in der Selektion, d.h.

der Satz ist nicht gesperrt.
2007 P1 2007 liegt nicht in der Selektion, d.h.

der Satz ist nicht gesperrt.
2008 P11 Beide Komponenten liegen nicht in

der Selektion, d.h. der Satz ist nicht
gesperrt.
Aktivitäten
Die Selektionstabellen müssen zentral für alle Benutzer und Applikationsserver abgelegt und verwaltet werden.
Der SAP-Standard-Sperrserver kann keine Sperren verwalten, die auf Selektionstabellen beruhen. Daher sind
hier für die Ablage der Sperren, die durch Selektionstabellen beschrieben werden, SAP BW∕4HANA-spezifische
Einstellungen vorzunehmen.
Die Einstellungen zur SAP BW∕4HANA-Sperrverwaltung sind über den SAP-Referenz-IMG (Transaktionscode
SPRO) oder direkt über die Pflege der Sperreinstellungen für die Planung (Transaktionscode RSPLSE)
zugänglich. Um die Planung zu nutzen, ist ein Sizing der verwendeten Sperrtabelle notwendig. Das Sizing ist
vom Ablageort der Sperrtabelle abhängig.
Verwalten der Sperreinstellungen [Seite 168]
Sizing der Sperrtabelle [Seite 175]
Planungskonzepte
1.12.1 Verwalten der Sperreinstellungen
Verwendung
Sie möchten Informationen über die Sperrverwaltung erhalten, um mit entsprechenden Einstellungen darauf
reagieren zu können.
Um in die Sperrserververwaltung zu gelangen, wählen Sie den Transaktionscode RSPLSE. Sie gelangen auf das
Bild Sperreinstellungen Planung anzeigen.
Voraussetzungen
Stellen Sie sicher, dass Sie die notwendigen Berechtigungen besitzen. Für die Anzeige und Änderung der
Sperreinstellungen der Planung gibt es ein entsprechendes Berechtigungsobjekt: S_RS_PLENQ.
Funktionsumfang
Auf den Registerkarten Sperrtabelle und Sperrmerkmale können Sie die gewünschten Änderungen im
Änderungsmodus vornehmen.
Registerkarte: Sperrtabelle
Hier können Sie die Ablage der Sperrtabelle festlegen (siehe Ablegen der Sperrtabelle [Seite 169]).
 Achtung
Sie können nur dann vom Anzeigemodus in den Änderungsmodus wechseln, wenn es für keinen Basis-
InfoProvider der Planung aktive Sperren gibt, d.h. wenn für keinen InfoProvider der Datenbasis
Bewegungsdaten einer Planungsanwendung gesperrt sind. Dies soll sicherstellen, dass gesperrte
Bewegungsdaten konsistent bleiben.
Registerkarte: Sperrmerkmale
Hier können Sie festlegen, welche Merkmale für die Sperren relevant sind (siehe Auswahl der Sperrmerkmale
[Seite 171]).
 Achtung
Sie können nur dann vom Anzeigemodus in den Änderungsmodus wechseln, wenn es keine aktiven
Sperren für den ausgewählten InfoProvider gibt, d.h. wenn für den jeweiligen InfoProvider der Datenbasis
keine Bewegungsdaten über eine Planungsanwendung gesperrt sind.
 Hinweis
Die Sperrmerkmale liegen in der Tabelle RSPLS_CHAS_LOCK. Diese Einstellungen lassen sich
transportieren, indem man die Tabelleneinträge direkt in einen Transportauftrag einträgt.
Planungskonzepte
Auf den Registerkarten Sperren, Sperrkonflikt und Master-Sperren können Sie sich die entsprechenden
Informationen anzeigen lassen.
Registerkarte: Sperren
Hier können Sie sich anzeigen lassen, welche Sperren für einen bestimmten InfoProvider und Benutzer gesetzt
sind (siehe Anzeige der aktiven Sperren [Seite 172]).
Registerkarte: Sperrkonflikt
Das System zeigt Informationen zum letzten Sperrkonflikt an (siehe Analyse eines Sperrkonfliktes [Seite
175]).
Registerkarte: Master-Sperren
Hier können Sie sich anzeigen lassen, welche Privilegsperren gesetzt sind, und diese ggf. löschen (siehe
Anzeige der Privilegsperren [Seite 173]).
1.12.2 Ablegen der Sperrtabelle
Verwendung
Die Selektionstabellen müssen zentral für alle Benutzer und Applikationsserver abgelegt und verwaltet werden.
Der SAP Standard-Sperrserver kann keine Sperren verwalten, die auf Selektionstabellen beruhen. Daher sind
hier für die Ablage der Sperren, die durch Selektionstabellen beschrieben werden, eigene Einstellungen
vorzunehmen.
In einer Sperrtabelle wird festgehalten, welche Sperren derzeit bestehen. Auf der Registerkarte Sperrtabelle
können Sie festlegen, wo die Sperrtabelle abgelegt werden soll. Es gibt drei Optionen zur Ablage der
Sperrtabelle; je nach der Art der Ablage können Sie einen geeigneten Server auswählen.
Funktionsumfang
Ablegen der Sperrtabelle im SAP Standard-Sperrserver
Die Selektionstabellen werden komprimiert in der Sperrtabelle des SAP Standard-Sperrservers abgelegt.
Die Kollisionsprüfung von Sperren erfolgt dabei nicht durch den Sperrserver selbst, sondern durch ein ABAP-
Programm. Diese Prüfung erfordert einen Kopiervorgang der Selektionstabellen in den Benutzerkontext. Die
Kollisionsprüfung erfolgt voreingestellt auf dem Server der Anmeldung. Wenn Sie statt dessen einen anderen,
festen Server auswählen, dann wird die Kollisionsprüfung dort mittels RFC-Aufruf durchgeführt.
Dies kann dann sinnvoll sein, wenn der Enqueue-Prozess nicht auf der Zentralinstanz, sondern auf einem
anderen (möglichst schnellen) Server installiert ist, um den Kopiervorgang von Selektionen aus der
Sperrtabelle in den Benutzerkontext eventuell zu beschleunigen. Der Server mit dem Enqueue-Prozess ist in
der Server-Auswahl speziell als solcher gekennzeichnet.
Planungskonzepte
 Hinweis
In der SAP-Sperrverwaltung (Transaktionscode SM12) können Sie die komprimierten Sperrsätze über den
Tabellennamen RSPLS_S_LOCK anzeigen lassen; die gesperrten Selektionen selbst finden Sie in der
Transaktion RSPLSE (siehe Anzeige der aktiven Sperren [Seite 172]).
 Empfehlung
Diese Option verlangt den geringsten Administrationsaufwand. Sie ist für kleine und mittlere Installationen
geeignet. Die Größe der Sperrtabelle kann über den Profilparameter enque/table_size eingestellt werden.
Ablegen der Sperrtabelle im Shared Object Memory eines Applikationsservers (Voreinstellung des
Systems)
Die Selektionstabellen werden unkomprimiert in einem Shared-Object-Memory-Bereich abgelegt. Dies ist die
Voreinstellung des Systems, es sei denn, Sie verwenden den SAP Standalone Engine Server; dann ist die obige
Option (Ablegen der Sperrtabelle im SAP Standard-Sperrserver) voreingestellt.
Dieser Bereich ist an einen Applikationsserver gebunden. Der SAP Standard-Sperrserver enthält in diesem Fall
nur einen Zeiger (genau einen Sperrsatz pro Selektionstabelle) auf die Selektion. Sie müssen einen Server
angeben, der die Sperrtabelle im Shared Object Memory enthalten und auf dem die Kollisionsprüfung erfolgen
soll. (Voreingestellt ist der Enqueue-Server.) Dadurch ist der Kopiervorgang von Selektionen aus der
Sperrtabelle in den Benutzerkontext nicht mehr notwendig. Wenn Sie auf einem anderen Server angemeldet
sind, dann wird die Kollisionsprüfung dort mittels RFC-Aufruf durchgeführt.
Auch hier kann es sinnvoll sein, den Enqueue-Prozess nicht auf der Zentralinstanz, sondern auf einem
(möglichst schnellen) Server zu installieren. Denn bei einem Sperrvorgang werden die Selektionen im Shared
Object Memory mit den Zeigern im SAP Standard-Sperrserver synchronisiert. Diese Synchronisation geschieht
am schnellsten, wenn der Server mit dem Enqueue-Prozess derselbe wie der mit der Sperrtabelle ist. Daher ist
diese Option in der Regel auch voreingestellt.
 Hinweis
In der SAP-Sperrverwaltung (Transaktionscode SM12) finden Sie pro gesperrter Selektion nur einen
Sperrsatz über den Tabellennamen RSPLS_S_LOCK_SYNC; die gesperrten Selektionen selbst finden Sie in
der Transaktion RSPLSE (siehe Anzeige der aktiven Sperren [Seite 172]).
 Empfehlung
Diese Option hat eine bessere Performance als das Ablegen der Sperrtabelle im SAP Standard-Sperrserver.
Allerdings muss die Verfügbarkeit des Servers mit der Sperrtabelle sichergestellt werden, wenn
Bewegungsdaten über Selektionen gesperrt werden sollen. Die Größe des Shared Object Memory kann
über den Profilparameter abap/shared_objects_size_MB eingestellt werden.
Planungskonzepte
1.12.3 Auswahl der Sperrmerkmale
Verwendung
Auf der Registerkarte Sperrmerkmale können Sie festlegen, welche Merkmale für die Sperrprüfung
herangezogen werden sollen.
● In der Voreinstellung sind zu einem DataMart DataStore-Objekt und einem lokalen Provider im BW
Workspace alle Merkmale und das Kunstmerkmal 1KYFNM für die Sperrprüfung relevant.
● In einem Direct Update DataStore-Objekt sind ebenfalls alle Merkmale in der Voreinstellung für die
Sperrprüfung relevant, das Kunstmerkmal 1KYFNM steht jedoch grundsätzlich nicht zur Verfügung. Das
bedeutet, dass Daten in Direct Update DataStore-Objekten immer unabhängig von den verwendeten
Kennzahlen der Planungsfunktion oder eingabebereiten Query gesperrt werden.
Um die Größe der Sperrtabelle zu verringern, können Sie solche Merkmale, die die Sperrselektionen nicht
separieren können, von der Sperrprüfung ausnehmen. Dazu gehören Merkmale, die für alle Benutzer gleiche
oder überlappende Werte haben.
Wenn kein Merkmal für die Sperren relevant ist, wird der gesamte InfoProvider gesperrt.
Aktivitäten
Auswahl von Sperrmerkmalen
1. Um in den Änderungsmodus zu gelangen, wählen Sie .

2. Wählen Sie einen InfoProvider aus. Der Bildbereich Auswahl Sperrmerkmale ist in der Voreinstellung leer,
da sämtliche Merkmale für die Sperrprüfung relevant sind.
3. Drücken Sie die Eingabetaste. Das System zeigt im Bildbereich Sperrmerkmale die aktuell ausgewählten
Sperrmerkmale an.
4. Entfernen Sie diejenigen Merkmale aus dem Bildbereich Sperrmerkmale, die für die Prüfung nicht relevant
sein sollen.
 Beispiel
In einer Kostenstellen-Planung werden meist die Merkmale Geschäftsjahr, Version, Kostenstelle und
Kostenart verwendet. Wenn viele Benutzer für das gleiche Jahr und die gleichen Kostenarten planen,
reichen eventuell die Merkmale Kostenstelle und Version aus, um die Selektionen der verschiedenen
Benutzer überschneidungsfrei zu machen. Legen Sie dann nur diese Merkmale als relevant für die
Sperren fest.
Auswahl von Navigationsattributen als Sperrmerkmale
In der Voreinstellung sind Navigationsattribute nicht relevant für die Sperren, d.h. sie sind immer komplett
gesperrt. Um die Selektionstabellen kleiner zu machen, kann es sinnvoll sein, einige Navigationsattribute
relevant für die Sperren zu machen. So könnten Sie z.B. Selektionen über eine Produktgruppe nutzen statt
Selektionen über umfangreiche Listen von Produkten, die zu dieser Produktgruppe gehören.
Im Expertenmodus können Sie Navigationsattribute in die Liste der Sperrmerkmale aufnehmen.
Planungskonzepte
 Hinweis
Der Modus kann über den ok_code EXPERT eingeschaltet und über NOEXPERT wieder ausgestellt werden.
 Achtung
Stellen Sie sicher, dass während der Durchführung der Planung keine Werte von Navigationsattributen
geändert werden. Sonst ist es nicht ausgeschlossen, dass verschiedene Benutzer die gleichen Werte des
zugehörigen Basismerkmals bearbeiten und somit beide neue Delta-Sätze schreiben können.
Benutzer 1 plant Produkt P1, welches in der Produktgruppe (Navigationsattribut) PG1 liegt. In der
Selektionstabelle werde PG1 selektiert, auf Produkt liege keine Einschränkung. Wenn über die
Produktgruppe gesperrt wird, kann folgendes passieren. Benutzer 2 plant Produktgruppe PG2: Erst steigt
Benutzer 1 ein, die Daten werden gesperrt. Während dieser Zeit wird das Attribut von Produkt P1 von PG1
auf PG2 geändert. Benutzer 2 steigt dann in die Planung ein. Da jetzt PG2 mit PG1 formal disjunkt ist, gibt
es keinen Sperrkonflikt. Beide Benutzer können aber Kennzahlwerte für Produkt P1 planen.
1.12.4 Anzeige der aktiven Sperren
Verwendung
Auf der Registerkarte Sperren können Sie sich (ähnlich zur SAP-Sperrverwaltung Sperreinträge selektieren,
Transaktionscode SM12) die aktuell gesperrten Selektionen pro InfoProvider und Benutzer ansehen.
Funktionsumfang
Tabelle Sperren: Kopfeinträge
Das System zeigt die Kopfeinträge zu jeder gesperrten Selektion an (InfoProvider, Benutzername, Sperrmodus,
Sperrsätze, Sperrhandle). Hierbei sind der Benutzername und die Anzahl der Sätze in dieser gesperrten
Selektion sowie der Sperrmodus interessant.
Es gibt folgende Sperrmodi:
● E(exclusive): Schreibsperre, die für alle Daten, die im Änderungsmodus bearbeitet werden, verwendet wird;
damit sind die Daten exklusiv für die Bearbeitung durch einen Benutzer geschützt.
● S(shared): Lesesperre, die zur Laufzeit z.B. Referenzdaten für Planungsfunktionen vor Änderungen
schützt.
 Hinweis
Weitere Informationen über die Sperrmodi finden Sie unter .
Das Sperrhandle (eine 32-stellige GUID) repräsentiert eine gesperrte Selektion.
Tabelle Sperrsätze
Planungskonzepte
Das System zeigt die gesperrten Selektionen an. Die Anzeige erfolgt gruppiert nach den Kopfeinträgen
(Sperrhandle), dem Merkmal, der Intervall-Art (Intervall) und der unteren und oberen Intervallgrenze der
Selektion (Merkmalswert intern). Die Selektionen selbst werden in der Sperrtabelle in einer Normalform
dargestellt: Jede Selektion ist pro Merkmal eine disjunkte Vereinigung von offenen, halboffenen oder
abgeschlossenen Intervallen.
Die Intervall-Art wird wie folgt angedeutet:
● ( ) für ein offenes Intervall

● [ ) bzw. ( ] für ein halboffenes Intervall
● [ ] für ein abgeschlossenes Intervall
Aktivitäten
1. Wählen Sie den InfoProvider aus. Das System ermittelt alle vorhandenen Sperren aus den
planungsrelevanten InfoProvidern, die in diesem InfoProvider (z.B. bei Aggregationsebenen oder
CompositeProvidern) enthalten sind.
2. Wählen Sie den Benutzer aus. Bei der Eingabe sind Wildcards der Form PRE* oder *ABC* erlaubt. Das
System listet die aktiven Sperren in den Tabellen Sperren: Kopfeinträge und Sperrsätze auf.
3. Benachrichtigen Sie die betroffenen Benutzer und löschen Sie ggf. die Sperren.
 Hinweis
Wenn Sie aktive Sperren löschen möchten, verwenden Sie die SAP-Sperrverwaltung (Transaktionscode
SM12). Je nach der Ablage der Sperrtabelle müssen Sie eine andere Sperrstruktur auswählen.
○ Sperrtabelle im SAP Sperrserver: Tabellenname RSPLS_S_LOCK.
○ Sperrtabelle im Shared Objects Memory: Tabellenname RSPLS_S_LOCK_SYNC.
In der SAP-Sperrverwaltung (Transaktionscode SM12) sehen Sie allerdings nicht, welche Datensätze
genau gesperrt sind. Dafür verwenden Sie die Pflege der Sperreinstellungen für die Planung
(Transaktionscode RSPLSE).
1.12.5 Anzeige der Privilegsperren
Verwendung
Mittels der privilegierten Datensperre kann sichergestellt werden, dass umfangreiche Planungssequenzen
nicht wegen Sperrkollisionen mit anderen Benutzern abbrechen. Auf der Registerkarte Master Sperren können
Sie die aktuell gesetzten Privilegsperren anzeigen und ggf. löschen.
Privilegsperren werden zur Laufzeit von Planungssequenzen auf der Ebene der planungsrelevanten
InfoProvider gesetzt, die als Schritte in Prozessketten eingebunden sind. Das System ermittelt vor der
Verarbeitung der Daten alle erforderlichen Selektionen. Für diese Selektionen wird zunächst versucht, eine
normale Sperre zu setzen. Wenn dies möglich ist, werden diese Selektionen als Privilegsperren gesichert, die
normalen Sperren werden danach aufgehoben. Von da an kann kein Benutzer Daten innerhalb dieses Bereichs
ändern.
Planungskonzepte
Die Prozesskette selbst wird im Normalfall im Hintergrund verarbeitet. Einzelne Teilprozesse können sich
gegenüber der Privilegsperre als privilegiert ausweisen, nur diese passieren die Privilegsperre. Während der
Laufzeit der Planungssequenz werden die zu verarbeitenden Daten wie üblich durch normale Sperren
geschützt. Nach Verarbeitung der Daten durch die Prozesskette werden die Privilegsperren wieder aufgehoben.
Integration
Privilegsperren werden ausschließlich von Planungssequenzen in Prozessketten gesetzt.
Funktionsumfang
Tabelle Master Sperren: Kopfeinträge
Die von einer Prozesskette gesetzten Privilegsperren bekommen ein Sperrhandle zugewiesen. Das System
zeigt die Kopfeinträge zu jeder gesperrten Selektion an ( Sperrhandle, InfoProvider, Prozesskette,
Prozessvariante).
Tabelle Sperrsätze
Das System zeigt die gesperrten Selektionen zu den Sperrhandles an. Die Anzeige erfolgt gruppiert nach den
Kopfeinträgen (Sperrhandle), den zusammengehörigen Selektionen (Nummer der Selektionstabelle), dem
Merkmal, der Intervall-Art (Intervall) und der unteren und oberen Intervallgrenze der Selektion (Merkmalswert
intern). Die Selektionen selbst werden in der Sperrtabelle in einer Normalform dargestellt: Jede Selektion ist
pro Merkmal eine disjunkte Vereinigung von offenen, halboffenen oder abgeschlossenen Intervallen.
Die Intervall-Art wird wie folgt angedeutet:
● ( ) für ein offenes Intervall

● [ ) bzw. ( ] für ein halboffenes Intervall
● [ ] für ein abgeschlossenes Intervall
Aktivitäten
1. Wählen Sie einen InfoProvider aus. Das System ermittelt alle vorhandenen Privilegsperren aus den
planungsrelevanten InfoProvidern oder Aggregationsebenen und stellt Sie Ihnen in der Übersicht dar.
2. Um eine Privilegsperre zu löschen, löschen Sie die entsprechende Zeile in der Tabelle Master Sperren:
Kopfeinträge.
 Hinweis
Auch nach Löschen einer Privilegsperre sind die Bewegungsdaten zur Laufzeit durch normale aktive
Sperren geschützt. Ohne die Privilegsperre aber können ggf. Teile von Planungssequenzen aufgrund
von Sperrkonflikten mit anderen Benutzern nicht ausgeführt werden.
Planungskonzepte
1.12.6 Analyse eines Sperrkonfliktes
Verwendung
Auf der Registerkarte Sperrkonflikt zeigt das System die Selektionen zum letzten aufgetretenen Sperrkonflikt
an. Sie erhalten folgende Informationen über den Kontext des Aufrufenden:
● InfoProvider
● Benutzer der Sperranfrage
● Benutzer mit Sperre, d.h. Benutzer der bereits gesperrten Selektion
● Datum und Zeitpunkt der Sperranfrage in Systemzeit
● Ob der Sperrkonflikt mit einer Privilegsperre auftrat ( Master Sperre)
Aktivitäten
Um die Ursache für den Sperrkonflikt zu identifizieren, vergleichen Sie die Selektionen aus den Tabellen
Selektion aus Sperranfrage und Gesperrte Selektion. Der Sperrkonflikt trat dort auf, wo sich die Selektionen
überlappen.
1.12.7 Sizing der Sperrtabelle
Verwendung
Für einen InfoProvider der Datenbasis der Planung sind für die Dauer einer Sperroperation keine anderen
Zugriffe auf den SAP BW∕4HANA-Sperrserver möglich. Der Sperrserver ist also eine ggf. knappe Ressource.
Daher ist es erforderlich, bei der Implementierung von Planungsanwendungen in einem SAP BW∕4HANA-
System ein Design zu wählen, das die Anzahl und Größe der Selektionen möglichst klein hält. Je kleiner die
Sperrtabelle ist, desto besser sind die Antwortzeiten des Sperrservers.
Sie können die Sperrtabelle dadurch verkleinern, dass Sie Merkmale, die die Selektion nicht separieren, aus der
Liste der für die Sperren relevanten Merkmale eines planungsrelevanten InfoProviders entfernen. Dazu
gehören Merkmale, die für alle Benutzer gleiche oder überlappende Werte annehmen. Weitere Informationen
finden Sie unter Auswahl der Sperrmerkmale [Seite 171].
Die folgenden Abschnitte enthalten Informationen zum Sizing der Sperrtabelle für die Planung. Es wird
erläutert, wie man den benötigten Speicherverbrauch ermitteln und dann die entsprechenden Profilparameter
einstellen kann.
 Hinweis
Weitere Informationen über die verschiedenen Möglichkeiten, die Sperrtabelle abzulegen, finden Sie unter
Ablegen der Sperrtabelle [Seite 169].
Aktuelle Sizing-Informationen finden Sie im SAP-Hinweis 928044 .
Planungskonzepte
Integration
Die aktuell gesetzten Werte können Sie in der Pflege der Profilparameter (Transaktionscode RZ11) anzeigen
lassen.
Funktionsumfang
Ablage der Sperrtabelle im SAP Standard-Sperrserver
Die Größe der Sperrtabelle des SAP Standard-Sperrservers kann über den Profilparameter enque/table_size
eingestellt werden.
Die Einstellung enque/table_size = 25.000 sollte für die meisten Systeme ausreichend sein, in denen die
Planung verwendet wird.
Genauer kann die Anzahl der benötigten Sperrsätze wie folgt abgeschätzt werden:
● Die Anzahl der aktiv genutzten planungsrelevanten InfoProvider als Datenbasis sei IC.
● Die durchschnittliche Anzahl der Zeilen in der Selektionstabelle sei Rec. Diese Anzahl können Sie für einen
repräsentativen Benutzer über die Pflege der Sperreinstellungen für die Planung (Transaktionscode
RSPLSE) ermitteln, indem Sie sich auf der Registerkarte Anzeige der aktiven Sperren die gesperrten
Selektionen anzeigen lassen.
● Die Anzahl der Sperranfragen pro Benutzer sei LReq. Diese Anzahl hängt vom Design der
Planungsanwendung ab: Anzahl der eingabebereiten Queries, Anzahl der verwendeten Planungsfunktionen
und wie oft diese Komponenten Daten im Änderungsmodus anfragen.
● Die Anzahl der aktiven Benutzer sei U.
● Der Komprimierungsfaktor für eine Selektionstabelle sei Compr. Dieser Faktor ist zwischen 5 und 10.
Die Anzahl der Sperrsätze NLCK ist dann:
NLCK = IC * U * LReq * Rec / Compr
Um festzustellen, wie viele Sperrsätze bei dem aktuellen Wert des Profilparameters enque/table_size in der
Sperrtabelle maximal abgelegt werden können, wählen Sie in der SAP-Sperrverwaltung (Transaktionscode
SM12) Zusätze Statistik . Sie finden den Wert in der Zeile Sperreinträge Tabelle, Groesse.
Ablage der Sperrtabelle im Shared Object Memory eines Applikationsservers (Voreinstellung des
Systems)
Die Größe der Sperrtabelle im Shared Object Memory eines Applikationsservers kann über den
Profilparameter abap/shared_objects_size_MB eingestellt werden.
Die Einstellung abap/shared_objects_size_MB = 200 sollte für die meisten Systeme ausreichend sein, in denen
die Planung verwendet wird.
Genauer kann die Anzahl der benötigten Sperrsätze wie folgt abgeschätzt werden:
● Die Anzahl der aktiv genutzten planungsrelevanten InfoProvider als Datenbasis sei IC.
● Die durchschnittliche Anzahl der Zeilen in der Selektionstabelle sei Rec. Die eigentlichen Selektionen liegen
zweimal im Shared Object Memory: einmal optimiert für Suchzugriffe pro Merkmal und einmal optimiert
für Zugriffe pro gesperrter Selektion (Sekundärindex). Die benutzte DDIC-Struktur hat eine Breite von 207
Planungskonzepte
Zeichen, also von 207 Byte (bzw. 414 Byte in Unicode-Systemen). Man kann mit etwa 1KByte pro Zeile der
Selektionstabelle rechnen.
● Die Anzahl der Sperranfragen pro Benutzer sei LReq. Diese Anzahl hängt vom Design der
Planungsanwendung ab: Anzahl der eingabebereiten Queries, Anzahl der verwendeten Planungsfunktionen
und wie oft diese Komponenten Daten im Änderungsmodus anfragen.
● Die Anzahl der aktiven Benutzer sei U.
Die Anzahl der Sperrsätze NLCK ist dann:
NLCK = IC * U * LReq * Rec
Daraus ergibt sich der benötigte Speicher in Kilobyte durch Multiplikation von NLCK mit dem Faktor 2, denn bei
einer Sperranfrage zieht das System für die Dauer einer Kollisionsprüfung eine Kopie der bereits gesperrten
Selektionen.
Informationen über den aktuell benötigten Speicher für den SAP BW∕4HANA-Sperrserver finden Sie in der
Shared Object Gebietsverwaltung (Transaktionscode SHMA): Rufen Sie diese Transaktion auf dem Server mit
der SAP BW∕4HANA-Sperrtabelle auf; verwenden Sie als Gebiet CL_RSPLS_ENQ_AREA.
Planungskonzepte
2 Planungsrelevante Objekte anlegen
Für die Modellierung planungsspezifischer Metadatenobjekte sowie für diejenigen wiederverwendbaren

Metadatenobjekten, die auch für Planung Relevanz haben, (Filter und Variablen) stehen Ihnen die BW-
Modellierungswerkzeugen zur Verfügung.
Funktionsumfang
Die BW-Modellierungswerkzeugen bieten Ihnen die folgenden Funktionen zur Bearbeitung planungsspezifischer
Metadatenobjekte:
● Aggregationsebenen
● Datenscheiben
● Merkmalsbeziehungen
● Planungsfunktionen
● Planungssequenzen
Für die manuelle Erfassung von Plandaten definieren Sie eine eingabebereiten Query.
Für die Anzeige der planungsspezifischen Metadatenobjekten zu einem bestimmten, im Editor der BW-
Modellierungswerkzeuge geöffneten Objekt verwenden Sie die den Planning View.

Datenscheibe anlegen [Seite 180]
Planungsfunktion anlegen [Seite 187]
Planungssequenz anlegen [Seite 188]
2.1 Aggregationsebene anlegen
Um Daten manuell planen oder über Planungsfunktionen verändern zu können, benötigen Sie einen
planungsspezifischen InfoProvider, die Aggregationsebene. Über die Aggregationsebene legen Sie die
Granularität der Planung fest, indem Sie nur die für die Planung relevanten Merkmale und Kennzahlen des
zugrunde liegenden InfoProviders aufnehmen.
Planungskonzepte
178 PUBLIC (ÖFFENTLICH) Planungsrelevante Objekte anlegen
Voraussetzungen
Sie haben eine SAP HANA-Datenbank im Einsatz. Sie haben die BW-Modellierungswerkzeuge installiert und
konfiguriert.
Sie haben einen für die Planung geeigneten InfoProvider als Grundlage der Aggregationsebene ausgewählt
(siehe Datenbasis InfoProvider [Seite 7]).
Kontext
Sie können mehrere Aggregationsebenen zu einem InfoProvider anlegen und so verschiedene Ebenen der
Planung und z.B. hierarchische Strukturen modellieren. Beachten Sie, dass Aggregationsebenen nicht
geschachtelt werden können.
Vorgehensweise
1. Legen Sie die Aggregationsebene an. Sie können eine Aggregationsebene im Project Explorer View
entweder zu einem BW-Projekt oder zu einer InfoArea anlegen. Außerdem können Sie eine
Aggregationsebene als Kopie einer bestehenden Aggregationsebene anlegen.
a. Wählen Sie aus dem Kontextmenü entweder zu einem BW-Projekt oder zu einer InfoArea New
Aggregation Level , oder wählen Sie aus dem Kontextmenü zu der als Vorlage gewünschten
Aggregationsebene Copy . Sie gelangen auf das Dialogfenster New Aggregation Level. Je nachdem,
welchen Einstieg Sie gewählt haben, hat das System die entsprechenden Objekte bereits
vorausgewählt.
b. In jedem Fall hat das System das aktuelle BW-Projekt vorausgewählt. Über Browse können Sie ggf. ein
anderes BW-Projekt auswählen.
c. Wenn Sie eine Aggregationsebene zu einem BW-Projekt angelegt haben, müssen Sie noch die
gewünschte InfoArea auswählen. Geben sie deren technischen Namen oder einen entsprechenden
Suchbegriff ein. Das System unterstützt Sie bei der Suche des technischen Namens und gibt eine Liste
der Ergebnisse im Bereich Matching items aus.
d. Wenn Sie eine Aggregationsebene zu einer InfoArea angelegt haben, hat das System diese InfoArea
vorausgewählt. Über Browse können Sie ggf. eine andere InfoArea auswählen.
e. Um Ihre Aggregationsebene Ihren lokalen Favoriten hinzuzufügen, wählen Sie Add to Favorites.
f. Geben Sie einen eindeutigen technischen Namen und eine Beschreibung für die Aggregationsebene
ein.
g. Geben Sie den gewünschten, für die Planung geeigneten InfoProvider an. Über Browse können Sie aus
der Liste aller geeigneten InfoProvider auswählen.
h. Wenn Sie eine Aggregationsebene als Kopie zu einer bereits bestehenden Aggregationsebene angelegt
haben, hat das System diese Aggregationsebene (und den ihr zugrundeliegenden InfoProvider)
vorausgewählt. Über Browse können Sie ggf. eine andere Aggregationsebene als Vorlage auswählen.
i. Wählen Sie Finish.
Das System öffnet die neue Aggregationsebene im nativen Eclipse-Editor. Sie gelangen auf die
Registerkarte General mit den bisher festgelegten Eigenschaften der Aggregationsebene.
Planungskonzepte
Planungsrelevante Objekte anlegen PUBLIC (ÖFFENTLICH) 179
2. Wählen Sie die Registerkarte Output. Sie gelangen zur Anzeige der Definition der Aggregationsebene.
Wenn Sie eine neue Aggregationsebene anlegen, ist der Bereich Provider Fields leer.
Wenn Sie eine Aggregationsebene als Kopie zu einer bestehenden Aggregationsebene angelegt haben,
zeigt das System im Bereich Provider Fields die ausgewählten Felder der zugrundeliegenden
Aggregationsebene.
3. Legen Sie fest, welche Merkmale und Kennzahlen in der Aggregationsebene zur Verfügung stehen sollen.
a. Wechseln Sie vom Project Explorer View zum InfoProvider View. Das System zeigt den der
Aggragationsebene zugrundeliegenden InfoProvider an.
b. Wählen Sie aus dem InfoProvider View die gewünschten Merkmale und Kennzahlen aus, und ziehen
Sie diese per Drag&Drop in die Definition der Aggregationsebene.
Per Klick auf ein Providerfeld zeigt das System im rechten Bildbereich die Eigenschaften des Objektes
an.
Per Klick auf den Link zum assoziierten Objekt öffnet das System die Anzeige des Objektes in einem
neuen Fenster.
 Hinweis
Die in der Aggregationsebene enthaltenen Kennzahlen werden über die nicht in der
Aggregationsebene enthaltenen Merkmale verdichtet.
c. Wenn Sie ein InfoObject entfernen möchten, wählen Sie aus dem Kontextmenü Remove...
4. Sichern Sie die Definition der Aggregationsebene.
○ Wenn Sie Sichern wählen, sichert das System die aktuelle Definition der Aggregationsebene als M-
Version.
○ Wenn Sie Aktivieren wählen, prüft das System die aktuelle Definition der Aggregationsebene und
sichert sie ggf. als A-Version. Das Ergebnis der Prüfung erscheint im Problems View.
Nach dem Aktivieren steht die Aggregationsebene für die weitere Verwendung zur Verfügung.

Einfache Aggregationsebene [Seite 26]
Komplexe Aggregationsebene [Seite 27]
Diese Links führen in die Dokumentation des Konzeptes der Aggregationsebene.
2.2 Datenscheibe anlegen
Mit Hilfe von Datenscheiben schützen Sie zentral Daten eines Basis-InfoProviders gegen Änderungen.
Planungskonzepte
Voraussetzungen
Sie haben den gewünschten Basis-InfoProvider, also ein DataStore-Objekt mit dem Kennzeichen Planning
Mode, gewählt. Beachten Sie, dass dieses einen aktiven Object State und Version State hat.
Wenn Sie mit einer Exit-Klasse arbeiten möchten, benötigen Sie ein ABAP-in-Eclipse-Projekt.
Kontext
Wenn Sie mit Hilfe von Datenscheiben Daten eines Basis-InfoProviders zentral gegen Änderungen, schützen,
wirkt sich dies auf alle InfoProvider der Planung aus, die diesen InfoProvider enthalten; es wirkt sich auch auf
alle eingabebereiten Queries und Planungsfunktionen aus, die diesen InfoProvider verwenden.
Vorgehensweise
1. Um eine Datenscheibe anzulegen, wählen Sie auf der Registerkarte General im Bildbereich Modeling
Properties den entsprechenden Link neben dem Feld Planning Mode.
Wenn es bereits eine Datenscheibe zu dem InfoProvider gibt, können Sie aus dem Kontextmenü des
gewünschten InfoProviders Open Data Slices wählen.
2. Wenn Sie eine neue Datenscheibe anlegen, müssen Sie zuerst den relevanten Transportauftrag zuweisen.
○ Wenn das Transportwesen in Ihrem System aktiv ist, gelangen Sie auf ein Dialogfenster zur Auswahl
des Transportauftrages. Wählen Sie den relevanten Transportauftrag aus.
○ Wenn das Transportwesen in Ihrem System nicht aktiv ist, sichert das System im Hintergrund
automatisch auf $TMP.
3. Sie gelangen auf die Registerkarte Data Slices. Im Bildbereich Data Slices sehen Sie alle ggf. bereits
vorhandenen Datenscheiben. Um Änderungen vorzunehmen, markieren Sie die gewünschte Datenscheibe.
4. Wenn Sie eine neue Datenscheibe anlegen möchten und diese auf einer Selektion beruhen soll, wählen Sie
Add Selection. Sie gelangen auf das Dialogfenster Edit Selection.
1. Markieren Sie das jeweils einzuschränkende Merkmal und übernehmen Sie es per Doppelklick oder
per Drag&Drop in die Spalte Selection Details.
2. Wählen Sie aus dem Kontextmenü zu dem Merkmal Restrict. Sie gelangen auf das Dialogfenster Edit
Filter. Schränken Sie das Merkmal ein:
○ auf einen einzelnen Merkmalswert
○ auf ein Merkmalswertintervall
○ auf variable Merkmalswerte
○ auf einem bestimmten Hierarchieknoten
○ auf einen variablen Hierarchieknoten
3. Wählen Sie OK.
4. Geben Sie der Datenscheibe im Bildbereich General eine Beschreibung.
5. Wenn Sie eine neue Datenscheibe anlegen möchten und diese auf einer Exit-Klasse beruhen soll, wählen
Sie Add user exit. Sie gelangen auf das Dialogfenster Edit Selection.
Planungskonzepte
1. Markieren Sie das jeweils einzuschränkende Merkmal und übernehmen Sie es per Doppelklick oder
per Drag&Drop in die Spalte Selection Details.
 Hinweis
Nur für diese Merkmale erhalten Sie die aktuellen Werte im Exit. Wenn Sie auch an Initialwerten im
Exit interessiert sind, setzen Sie im Bildbereich Selection das Kennzeichen in der Spalte # is Used.
2. Wählen Sie die gewünschte Exit-Klasse. Es steht eine Werthilfe zur Verfügung.
 Hinweis
Die Exit-Klasse muss das Interface 'IF_RSPLS_DS_EXIT' implementieren; in der Pflege werden nur
solche Klassen zur Bearbeitung angeboten. Wir empfehlen, dass die Kundenklasse von der
Vorlageklasse 'CL_RSPLS_DS_EXIT_BASE' erbt. Die Vorlageklasse selbst ist direkt lauffähig, führt
jedoch noch keine Aktion aus. Reimplementieren Sie die Methode 'IS_PROTECTED'. Beachten Sie
auch den auskommentierten Beispiel-Quelltext in der Vorlageklasse; dort wird z.B. eine
Infrastruktur für eine Pufferung angeboten.
3. Wählen Sie OK.

4. Geben Sie der Datenscheibe im Bildbereich General eine Beschreibung.
5. Setzen Sie im Bildbereich Selection für diejenigen Merkmale das Kennzeichen in der Spalte # is Used,
bei denen auch ihr Initialwert im Exit berücksichtigt werden soll.
 Hinweis
Wenn dieses Kennzeichen für ein Merkmal nicht gesetzt wird, wird der Exit z.B. nicht für diejenigen
Aggregationsebenen aufgerufen, die dieses Merkmal nicht enthalten, da der betreffende
Merkmalswert in diesen Fällen initial wäre.
6. Ordnen Sie die Schritte in der gewünschten Reihenfolge, indem Sie sie mit Up oder Down in der Liste nach
oben oder unten verschieben.
7. Setzen Sie das Kennzeichen Active für diejenigen Schritte, die berücksichtigt werden sollen.
8. Entfernen Sie einen Schritt, der nicht benötigt wird, über Remove.
2.3 Merkmalsbeziehung anlegen
Merkmalsbeziehungen dienen dazu, inhaltlich korrespondierende Merkmale miteinander in Beziehung zu

setzen.
Kontext
Sie haben den gewünschten Basis-InfoProvider, also ein DataStore-Objekt mit dem Kennzeichen Planning
Mode, gewählt. Beachten Sie, dass dieses einen aktiven Object State und Version State hat.
Planungskonzepte
Vorgehensweise
1. Um eine Merkmalsbeziehung anzulegen, wählen Sie auf der Registerkarte General im Bildbereich Modeling
Properties den entsprechenden Link neben dem Feld Planning Mode.
Wenn es bereits eine Merkmalsbeziehung zu dem InfoProvider gibt, können Sie aus dem Kontextmenü des
gewünschten InfoProviders Open Characteristic Relation wählen.
2. Wenn Sie eine neue Merkmalsbeziehung anlegen, müssen Sie zuerst den relevanten Transportauftrag
zuweisen.
○ Wenn das Transportwesen in Ihrem System aktiv ist, gelangen Sie auf ein Dialogfenster zur Auswahl
des Transportauftrages. Wählen Sie den relevanten Transportauftrag aus.
○ Wenn das Transportwesen in Ihrem System nicht aktiv ist, sichert das System im Hintergrund
automatisch auf $TMP.
3. Sie gelangen auf die Registerkarte General Settings der Merkmalsbeziehung. Auf dieser Registerkarte
können Sie für den gewählten InfoProvider zentrale Einstellungen vornehmen, die im ganzen
Planungsmodell gelten, soweit dieses auf diesem InfoProvider beruht.
4. Wählen Sie die Registerkarte Characteristic Relations. Im Bildbereich Relations können Sie über die
entsprechenden Drucktasten Merkmalsbeziehungen vom Typ DSO, Exit Class, Attribute oder Hierarchy
hinzufügen, nach oben oder unten verschieben oder auch wieder entfernen.
5. Wählen Sie den Typ der Merkmalsbeziehung aus.
6. Wählen Sie die Basis der Merkmalsbeziehung aus.
Diese ist für den jeweiligen Beziehungstyp verschieden:
○ Typ Attribut: ein stammdatentragendes Merkmal

○ Typ Hierarchie: das Hierarchiebasismerkmal
○ Typ DataStore: ein DataStore-Objekt
○ Typ Exit: eine Exit-Klasse.
7. Im Bildbereich General legen sie fest, ob das System eine Ableitung des Zielmerkmals aus dem
Basismerkmal durchführen soll. Weiterhin können Sie festlegen, dass diese Ableitung auch bei der Prüfung
der Kombinationen und für die Kombinationsvorschläge zugrundegelegt werden soll.
8. Definieren Sie entsprechend dem gewählten Beziehungstyp die weiteren Einstellungen.
9. Bevor Sie die Registerkarte verlassen, sichern Sie die definierte Merkmalsbeziehung. Das System sichert
die Merkmalsbeziehung automatisch in aktiver Version.

Registerkarte Characteristic Relations [Seite 184]
Diese Links führt in die Dokumentation der Aufgaben.
Dieser Link führt in die Dokumentation der Konzepte.
Planungskonzepte
2.3.1 Registerkarte General Settings
Auf dieser Registerkarte können Sie für den gewählten InfoProvider zentrale Einstellungen vornehmen, die im
ganzen Planungsmodell gelten, soweit dieses auf diesem InfoProvider beruht.
Im Anzeigemodus können Sie sich einen Überblick über die im System vorhandenen Einstellungen
verschaffen.
Im Änderungsmodus können Sie folgende Einstellungen vornehmen:
1. Im Bildbereich Key Date können Sie abweichend vom Standardwert ein fixes Datum oder einen
Variablenwert als Standardstichtag festlegen. Dieser Stichtag wird in allen zeitabhängigen Objekten der
Planung verwendet, etwa in Merkmalsbeziehungen, Datenscheiben und im Planungspuffer (Werte
zeitabhängiger Navigationsattribute).
2. Im Feld Maximum Number of Created Combinations können Sie die Anzahl der Kombinationen festlegen,
die das System für den gewählten InfoProvider maximal erzeugen soll.
3. Im Bildbereich Save Plan Data können Sie festlegen, ob das System die Daten des gewählten InfoProviders
vor dem Sichern mittels einer Planungssequenz auf ihre Gültigkeit prüfen und auf welcher Grundlage
geänderte Daten gelesen werden sollen.
○ Im Feld Planning Sequence When Saving können Sie die Planungssequenz angeben, die die zu
sichernden Daten dieses InfoProviders prüft. Über Browse steht eine Wertehilfe zur Verfügung.
Wenn die Planungssequenz einen Fehler meldet, werden die Daten nicht gesichert.
○ Sie können festlegen, welche Daten die Planungsfunktion verarbeitet. Diese Daten werden über die
Filter beschrieben, die in der Planungssequenz hinterlegt sind. Mit der Einstellung Only Read Changed
Data werden diese Filter zur Laufzeit der Sequenz jedoch so angepasst, das sie eine möglichst kleine
Obermenge der Daten beschreiben, die in der User Session verändert und noch nicht auf der
Datenbank gespeichert wurden. Diese Einstellung ist ggf. performancerelevant, da im Allgemeinen
weniger Datensätze verarbeitet werden.
Only Read Changed Data ist performancerelevant.
○ Im Feld Aggregation Level For Reading Changed Data Only können Sie diejenige Aggregationsebene
angeben, über die die geänderten Daten gelesen werden sollen. Über Browse steht eine Wertehilfe zur
Verfügung.
2.3.2 Registerkarte Characteristic Relations
Auf dieser Registerkarte können Sie abhängig vom jeweiligen Typ der Merkmalsbeziehung Einstellungen
vornehmen.
Abhängig von Ihrer Auswähl im Feld Derivation können Sie entweder Prüfmerkmale in der Tabelle Used
Characteristics oder die Quell- und Zielmerkmale in den Tabellen Source und Target auswählen:
● Wenn Sie keine Ableitung gewählt haben, können Sie Prüfmerkmale auswählen.
● Wenn Sie mit Ableitung gewählt haben, können Sie Quell- und Zielmerkmale auswählen und diese
entweder über die Drucktasten Add und Remove oder per Drag&Drop zwischen den beiden Tabellen hin-
und herschieben.
Planungskonzepte
Typ Attribut
Als Zielmerkmal sind die Attribute des Basismerkmals auswählbar. Die vorhandenen Kombinationen aus
Merkmals- und Attributswerten werden als zulässige Kombinationen interpretiert.
 Beispiel
Das Merkmal Währung ist ein Attribut des Merkmals Kostenrechnungskreis.
Wenn Sie ein anderes Basismerkmal verwenden möchten, löschen Sie die aktuelle Merkmalsbeziehung und
legen eine neue mit dem gewünschten Basismerkmal an.
Typ Hierarchie
Als Quell- bzw. Zielmerkmale sind alle Merkmale verfügbar, die in der InfoObject-Pflege als Externe Merkmale in
Hierarchie festgelegt wurden. Die Hierarchie muss neben dem Hierarchiebasismerkmal mindestens ein
weiteres Merkmal enthalten.
Als Quell- bzw. Zielmerkmal ist jeweils nur ein Merkmal erlaubt (hierbei werden die übergeordneten Merkmale
bei geklammerten Merkmale nicht mitgezählt).
Die zulässigen Kombinationen werden aus der Hierarchiestruktur entnommen. Dieselbe Hierarchie kann in
mehreren Relationen verwendet werden: In einem Schritt leitet man aus dem Hierarchiebasismerkmal ein
Merkmal auf der nächst höheren Ebene ab; in einem zweiten Schritt aus diesem Merkmal, dann wieder ein
Merkmal aus der nächsten Ebene.
Wenn die Hierarchie versions- und/oder zeitabhängig ist, können Sie auch vom Basismerkmal abweichende
Einstellungen zur Version und/oder zum Stichtag vornehmen. Dafür können die verwendeten Hierarchien auch
mit den passenden Variablen parametrisiert werden.
In einer bereits angelegten Merkmalsbeziehung können Sie das Basismerkmal nicht ändern, aber Sie können
eine andere Hierarchie auswählen. Auswählbar sind alle Hierarchien zu dem Basismerkmal. Wenn Sie ein
anderes Basismerkmal verwenden möchten, löschen Sie die aktuelle Merkmalsbeziehung und legen eine neue
mit dem gewünschten Basismerkmal an.
Typ DataStore-Objekt
Die im DataStore-Objekt enthaltenen Datensätze legen die gültigen Merkmalskombinationen fest bzw. dienen
zur Merkmalsableitung.
Nur Kombinationsprüfung: Sie können alle InfoObjects des DataStore-Objektes (außer Kennzahlen)
auswählen. Wenn Sie das Kennzeichen With Subsets setzen, wird die Relation auch dann angewendet, wenn
eine nicht-leere Teilmenge von Merkmalen der Relation in der Aggregationsebene vorkommt. Die Relation
definiert dann genau die Kombinationen des DataStore-Objekts als gültig, die durch Projektion der Sätze des
DataStore-Objekts auf die Teilmenge entstehen. Wir empfehlen, alle Merkmale im Schlüssel des DataStore-
Objektes entweder in die Merkmalsbeziehung aufzunehmen oder durch einen Einzelwert als Einschränkung in
der Relation festzulegen.
Planungskonzepte
Mit Ableitung: Als Quellmerkmale können Sie die Schlüssel des DataStore-Objektes auswählen. Als
Zielmerkmale stehen die InfoObjects aus dem Datenteil des DataStore-Objektes (außer Kennzahlen) zur
Auswahl. Jedes ausgewählte Merkmal darf nur in einer der beiden Tabellen vorkommen.
Die Schlüssel des DataStore-Objektes können mit einer Einschränkung versehen werden. Wenn Sie in der
Tabelle Restriction Einschränkungen hinterlegen, zieht das System dann den durch diese Einschränkungen
festgelegten Teil zur Kombinationsprüfung bzw. Ableitung heran. Sie können die Einschränkungen auch mit
Variablen parametrisieren, die dann aber ohne Dialog ersetzbar sein müssen.
 Hinweis
Beachten Sie, wenn Sie ein geklammertes Merkmal einschränken, braucht der Klammervater nicht in die
Tabelle Restriction aufgenommen zu werden.
Typ Exit
Die gültigen Merkmalskombinationen bzw. ableitbaren Merkmalswerte ergeben sich aus der
kundenspezifischen Implementierung der angegebenen Exit-Klasse. Über den Link Exit Class gelangen Sie zur
Auswahl eines ABAP-in-Eclipse-Projektes, in dem Sie dann die Exit-Klasse anzeigen und ändern können.
Die Exit-Klasse muss das Interface IF_RSPLS_CR_EXIT implementieren; in der Pflege werden nur solche
Klassen zur Bearbeitung angeboten. Wir empfehlen, die eigene Klasse von der Beispielklasse
CL_RSPLS_CR_EXIT_BASE abzuleiten. Sie müssen dann nur die Methoden CHECK, DERIVE und ggf. CREATE
implementieren. Die Klasse CL_RSPLS_CR_EXIT_BASE selbst ist direkt lauffähig, führt jedoch noch keine
Aktion aus.
 Nicht vergessen
Beachten Sie dort auch die Dokumentation zu den Attributen und Methoden der Klasse in der Transkation
SE24. Wenn Sie Zugriffe auf die bereits gelesenen Datensätze in den Methoden CHECK, DERIVE, CREATE
puffern möchten, können Sie diese Aufgabe dem System übertragen und müssen dies nicht im Exit
implementieren. Dazu setzen Sie im CONSTRUCTOR der Exit-Klasse das Attribut N_USE_EXTERNAL_BUFFER
im Interface IF_RSPLS_CHAR_RELATION. Beachten Sie weiterhin, dass Sie die Methode CREATE in jedem
Fall implementieren sollten, denn das System ruft diese Methode immer dann auf, wenn auf der Grundlage
von Merkmalsbeziehungen für die Merkmale der Relation Kombinationen erzeugt werden sollten, etwa in
eingabebereiten Queries (Zugriffsart für Ergebniswerte, Wertehilfe im dynamischen Filter oder in neuen
Zeilen) und in einigen Planungsfunktionstypen.
Sie können für Ihre Merkmalsbeziehung die Exit-Klasse auch im Nachhinein wechseln, da die Liste der
Merkmale aus dem zugrundeliegenden InfoProvider davon unabhängig ist. Sie können alle Merkmale und
geklammerten Merkmale aufnehmen.
 Hinweis
Beachten Sie, wenn zwei geklammerte Merkmale ein und denselben Klammervater haben und das eine in
die Tabelle Source aufgenommen wird und das andere in die Tabelle Target, so wird der Klammervater in die
Tabelle Source aufgenommen.
Planungskonzepte
2.4 Planungsfunktion anlegen
Planungsfunktionen dienen der Planung zur systemgestützten Bearbeitung bzw. Erzeugung von Daten. Um
eine Planungsfunktion verwenden zu können, definieren Sie den Typ der Planungsfunktion und die
Aggregationsebene, auf der die Planungsfunktion arbeiten soll. Weiterhin können Sie die
Merkmalsverwendung, die Bedingungen und die zugehörigen Parametersätze festlegen.
Voraussetzungen
Sie haben folgende Objekte angelegt:
● Aggregationsebene, auf welcher die Planungsfunktion angelegt wird.

● Filter, der zum Zeitpunkt der Ausführung den Planungsfunktionen mitgegeben wird. Die Planungsfunktion
sperrt die über den Filter definierten Daten in denjenigen Basis-InfoProvidern, die an der
Aggregationsebene teilhaben. Der Filter muss auf derselben Aggregationsebene definiert sein wie die
Planungsfunktion.
Kontext
Sie können Planungsfunktionen anlegen, kopieren, löschen, ändern, prüfen und sichern.
Vorgehensweise
1. Sie befinden sich im Project Explorer. Wählen Sie aus dem Kontextmenü zu einer InfoArea Ihres Projektes
New Planning Function . Sie gelangen auf ein Dialogfenster zum Anlegen einer Planungssequenz.
2. Geben Sie einen Namen und eine Beschreibung ein.
3. Wählen Sie die Aggregationsebene aus, auf der die Planungsfunktion angelegt werden soll. Es steht eine
Wertehilfe zur Verfügung.
4. Wählen Sie den Standard-Planungsfunktionstyp aus, den die Planungsfunktion soll. Es steht eine
Wertehilfe zur Verfügung.
5. Über Copy from können Sie eine Planungsfunktion als Vorlage verwenden. Es steht eine Wertehilfe zur
Verfügung.
Planungskonzepte
6. Wählen Sie Finish. Sie gelangen in die Pflege der Planungsfunktion auf die Registerkarte General. Im
Bildbereich General sehen Sie den technischen Namen, die Beschreibung, den Namen der
zugrundeliegenden Aggregationsebene, den gewählten Planungsfunktionstyp und einen Hilfetext. Diesem
können Sie entnehmen, was die Funktion leistet und wie Sie sie weiter gestalten können.
7. Im Bildbereich Characteristic Usage (Merkmalsverwendung) sehen Sie alle zur verfügung stehenden
Merkmale. Wählen Sie diejenigen Merkmale aus, die verändert werden sollen,und diejenigen, die in die
Bedingung eingehen sollen.
8. Wechseln Sie auf die Registerkarte Parameters.
Diese Registerkarte wird immer angezeigt, auch wenn der Planungsfunktionstyp keine Parameter hat.
9. Im Bildbereich Conditions können Sie Bedingungen hinzufügen,bearbeiten, duplizieren, entfernen und ihre
Reihenfolge verändern.
10. Im Bildbereich Parameters können Sie die Parameter spezifisch für den jeweiligen Planungsfunktionstyp
definieren.
11. Prüfen Sie die Planungsfunktion.
Beim Prüfen müssen für vorhandene eingabepflichtige Variablen, für die in der aktuellen Sitzung noch
keine Werte gewählt wurden, Werte angegeben werden. Dazu erscheint in diesen Fällen ein Eingabefenster.
12. Sichern Sie die Planungsfunktion.
Planungsfunktionen können auch dann gesichert werden, wenn sie nicht konsistent sind.
13. Führen Sie die Planungsfunktion aus.
Um eine Planungsfunktion ausführen zu können, müssen Sie diese zunächst in eine Planungssequenz
einbinden. Vor dem Ausführen der Planungsfunktion prüft das System stets, ob die Planungsfunktion
konsistent ist.

Standard-Planungsfunktionstypen [Seite 41]
2.5 Planungssequenz anlegen
Mit Hilfe einer Planungssequenz können Sie Planungsfunktionen gruppieren, in einer sortierten Reihenfolge
abspeichern und die gesamte Gruppe sortiert ausführen. Sie können auch Schritte zur manuellen
Dateneingabe in eine Planungssequenz einfügen.
Voraussetzungen
Sie haben die gewünschten Planungsfunktionen angelegt.
Planungskonzepte
Kontext
Sie können eine Planungssequenz anlegen, ändern, ausführen sowie mit allen Unterelementen kopieren.
Vorgehensweise
1. Sie befinden sich im Project Explorer. Wählen Sie aus dem Kontextmenü zu Ihrem Projekt oder zu einer
InfoArea Ihres Projektes New Planning Sequence... . Sie gelangen auf ein Dialogfenster zum Anlegen
einer Planungssequenz.
2. Wenn Sie die Planungssequenz zu einem Projekt anlegen, müssen Sie jetzt die gewünschte InfoArea
auswählen. Es steht eine Wertehilfe zur Verfügung.
3. Geben Sie einen Namen und eine Beschreibung ein.
4. Über Copy from können Sie eine Planungssequenz als Vorlage verwenden. Es steht eine Wertehilfe zur
Verfügung.
5. Wählen Sie Finish. Sie gelangen in die Pflege der Planungssequenz auf die Registerkarte Steps.
6. Wenn Sie einen Schritt hinzufügen möchten, wählen Sie Add. Sie gelangen auf das Dialogfenster Add
Planning Sequence Step.
7. Wählen Sie den Typ des Schrittes aus: Planning Function oder Manual Input.
8. Wählen sie die zugrundeliegende Aggregationsebene aus.
 Achtung
Wenn Sie einen Schritt auf einer Aggregationsebene definiert haben, empfehlen wir nicht, die
Aggregationsebene zu ändern. Falls dies nötig sein sollte, entfernen Sie den Schritt und legen Sie einen
neuen Schritt auf der Grundlage der gewünschten Aggregationsebene an.
9. Um den Schritt in Ihre Planungssequenz zu übernehmen, wählen Sie OK. Sie gelangen auf die
Registerkarte Steps zurück.
10. Wählen Sie im Bildbereich General den gewünschten Filter und ggf. die Planungsfunktion aus. Zur Auswahl
stehen diejenigen Objekte, die für die gewählte Aggregationseben zur Verfügung stehen. Gemeint sind hier
also die (wiederverwendbaren) Filter.
Wenn Sie einen Schritt vom Typ Manual Input anlegen, müssen Sie einen Filter definieren. Andernfalls
erhalten Sie eine Fehlermeldung.
Wenn Sie Änderungen an einer Planungsfunktion vornehmen möchten, klicken Sie auf den Link Planning
Function im Bildbereich General. Sie gelangen in den SAP GUI zur Bearbeitung von Planungsfunktionen.
Im Bildbereich General stehen Ihnen zwei weitere global für die ganze Planungssequenz geltende
Einstellungen zur Vefügung:
○ Reprocess Variables: Wenn Sie diese Option wählen, werden die Variablen vor dem Ausführen neu
prozessiert.
○ No Data Slice Check: Wenn Sie diese Option wählen, berücksichtigt die Planungssequenz zur
Ausführungszeit keine Datenscheiben. Dies kann für spezielle Fälle interessant sein. Beachten Sie,
dass andere Benutzer und in anderen Sessions die Datenscheiben aber weiterhin gültig sind.
11. Gestalten Sie Ihre Planungssequenz:
Planungskonzepte
○ Über Duplicate können Sie einen Schritt kopieren (und dann ggf. ändern).
○ Über Up können Sie einen Schritt nach oben verschieben. Er wird dann früher ausgeführt.
○ Über Down können Sie einen Schritt nach unten verschieben. Er wird dann später ausgeführt.
○ Über Remove können Sie einen Schritt entfernen.
12. Wenn Sie die Planungssequenz definiert haben, können Sie diese ausführen. Wählen Sie dazu aus der
Funktionsleiste Execute Planning Sequence. Sie gelangen in den SAP GUI im Anzeigemodus. Hier können
Sie die Planungssequenz schrittweise oder insgesamt ausführen.
 Hinweis
Beachten Sie, dass Schritte vom Typ Manual Input bei der Ausführung nicht berücksichtigt werden.
13. Um die Planungssequenz mit all ihren Unterelementen (Filtern und Planungsfunktionen) zu kopieren,
wählen Sie aus der Funktionsleiste Deep Copy of Planning Sequence. Sie gelangen in den SAP GUI im
Anzeigemodus. Hier können Sie auswählen, welche Unterelemente kopiert werden sollen. Standardmäßig
erhalten die kopierten Elemente im technischen Namen den Präfix CP_ und in der Beschreibung Copy
of .
 Hinweis
Beachten Sie, dass die Aggragationsebene nicht kopiert wird.
Planungskonzepte
Ausschlussklauseln und rechtliche Aspekte
Hyperlinks
Einige Links werden durch ein Symbol und/oder einen Quick-Info-Text klassifiziert. Über diese Links erhalten Sie weitere Informationen.
Informationen zu den Symbolen:
● Links zum Symbol : Sie rufen eine Website auf, die nicht von SAP gehostet wird. Durch die Nutzung solcher Links stimmen Sie Folgendem zu (sofern sich
nicht aus Ihren Vereinbarungen mit SAP etwas anderes ergibt):
● Der Inhalt der verlinkten Site ist keine SAP-Dokumentation. Basierend auf diesen Informationen ergibt sich für Sie keinerlei Produkthaftungsanspruch
gegen SAP.
● Weder widerspricht SAP dem Inhalt auf der verlinkten Site noch stimmt SAP ihm zu. Außerdem übernimmt SAP keine Gewährleistung für dessen
Verfügbarkeit und Richtigkeit. SAP übernimmt keine Haftung für Schäden, die durch die Nutzung solchen Inhalts verursacht wurden, es sei denn, dass
diese Schäden von SAP grob fahrlässig oder vorsätzlich verursacht wurden.
● Links zum Symbol : Sie verlassen die Dokumentation für das jeweilige SAP-Produkt oder den jeweiligen SAP-Service und rufen eine von SAP gehostete
Website auf. Durch die Nutzung solcher Links stimmen Sie zu (sofern sich nicht aus Ihren Vereinbarungen mit SAP etwas anderes ergibt), dass sich basierend
auf diesen Informationen für Sie keinerlei Produkthaftungsanspruch gegen SAP ergibt.
Beta und andere experimentelle Funktionen

Experimentelle Funktionen sind nicht Teil des offiziellen Lieferumfangs, den SAP für künftige Releases garantiert. Dies bedeutet, dass experimentelle Funktionen von
SAP jederzeit, aus beliebigen Gründen und ohne vorherige Ankündigung geändert werden können. Experimentelle Funktionen sind nicht zur Nutzung in einem
Produktivsystem vorgesehen. Die experimentellen Funktionen dürfen nicht für Demonstrationen, Tests, Untersuchungen, Bewertungen oder anderweitige Zwecke in
einer Produktivumgebung oder in Verbindung mit Daten, die nicht ausreichend gesichert wurden, verwendet werden.
Der Zweck der experimentellen Funktionen besteht darin, frühzeitig Feedback zu erhalten und so Kunden und Partnern die Möglichkeit zu geben, das zukünftige
Produkt entsprechend zu beeinflussen. Durch die Abgabe von Feedback (z.B. über SAP Community) stimmen Sie zu, dass die geistigen Eigentumsrechte der Beiträge
oder daraus abgeleiteten Werke im ausschließlichen Besitz von SAP verbleiben.
Beispielcode
Bei dem Quelltext und/oder den Code-Snippets handelt es sich ausschließlich um beispielhafte Darstellungen. Sie sind nicht zur Nutzung in einem Produktivsystem
vorgesehen. Der Beispielcode dient ausschließlich dem Zweck, Syntax- und Verphrasungsregeln besser zu erläutern und zu visualisieren. SAP übernimmt keine
Gewährleistung für die Richtigkeit und Vollständigkeit des Beispielcodes. SAP übernimmt keine Haftung für Fehler oder Schäden, die durch die Nutzung des
Beispielcodes verursacht wurden, es sei denn, dass diese Fehler oder Schäden von SAP grob fahrlässig oder vorsätzlich verursacht wurden.
Geschlechtsneutrale Sprache
Sofern möglich, wird geschlechtsneutral formuliert. Je nach Kontext und zur besseren Lesbarkeit kann SAP die männliche Flexionsform verwenden, um sich auf alle
Geschlechter zu beziehen.
Planungskonzepte
Ausschlussklauseln und rechtliche Aspekte PUBLIC (ÖFFENTLICH) 191
www.sap.com/contactsap
© 2019 SAP SE oder ein SAP-Konzernunternehmen Alle Rechte

vorbehalten.
Weitergabe und Vervielfältigung dieser Publikation oder von Teilen

daraus sind, zu welchem Zweck und in welcher Form auch immer, ohne
die ausdrückliche schriftliche Genehmigung durch SAP SE oder ein SAP-
Konzernunternehmen nicht gestattet. In dieser Publikation enthaltene
Informationen können ohne vorherige Ankündigung geändert werden.
Die von SAP SE oder deren Vertriebsfirmen angebotenen

Softwareprodukte können Softwarekomponenten auch anderer
Softwarehersteller enthalten. Produkte können länderspezifische
Unterschiede aufweisen.
Die vorliegenden Unterlagen werden von der SAP SE oder einem SAP-
Konzernunternehmen bereitgestellt und dienen ausschließlich zu
Informationszwecken. Die SAP SE oder ihre Konzernunternehmen
übernehmen keinerlei Haftung oder Gewährleistung für Fehler oder
Unvollständigkeiten in dieser Publikation. Die SAP SE oder ein SAP-
Konzernunternehmen steht lediglich für Produkte und Dienstleistungen
nach der Maßgabe ein, die in der Vereinbarung über die jeweiligen
Produkte und Dienstleistungen ausdrücklich geregelt ist. Keine der hierin
enthaltenen Informationen ist als zusätzliche Garantie zu interpretieren.
SAP und andere in diesem Dokument erwähnte Produkte und

Dienstleistungen von SAP sowie die dazugehörigen Logos sind Marken
oder eingetragene Marken der SAP SE (oder von einem SAP-
Konzernunternehmen) in Deutschland und verschiedenen anderen
Ländern weltweit. Alle anderen Namen von Produkten und
Dienstleistungen sind Marken der jeweiligen Firmen.
Zusätzliche Informationen zur Marke und Vermerke finden Sie auf der
Seite https://www.sap.com/germany/about/legal/trademark.html.
THE BEST RUN

SAP Planungskonzepte DE PDF

Hochgeladen von

Dokumentinformationen

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

SAP Planungskonzepte DE PDF

Hochgeladen von

Copyright:

Verfügbare Formate

© 2019 SAP SE oder ein SAP-Konzernunternehmen Alle Rechte vorbehalten.

THE BEST RUN

2 Planungsrelevante Objekte anlegen. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 178

Das Planungsmodell umfasst folgende Elemente:

● Daten (abgelegt in für Planung geeigneten InfoProvidern)

1. Datenbasis anlegen und Sperren verwalten

3. Eingabebereite Query definieren

Datenbasis InfoProvider [Seite 7]

1.1 Konzepte zum Schutz von Daten gegen Änderungen

Datenscheiben [Seite 15]

1.2 Datenbasis InfoProvider

Für die Planung geeignete Basis-InfoProvider

Für die Planung geeignete CompositeProvider

Folgende zusammengesetzte InfoProvider sind als Basis für Aggregationsebenen geeignet:

Merkmalsbeziehungen und Datenscheiben

Merkmalsbeziehungen dienen dazu, inhaltlich korrespondierende Merkmale miteinander in Beziehung zu

Um Merkmalsbeziehungen definieren zu können, müssen folgende Voraussetzungen erfüllt sein:

Definition einer Merkmalsbeziehung

Verhalten bei Kombinationsprüfung ohne und mit Ableitung

Besonderheiten beim initialen Merkmalswert (# nicht zugeordnet)

● Kombinationsprüfung ohne Ableitung:

Datenbasis InfoProvider [Seite 7]

1.2.2 Merkmalsbeziehungen für Zeitmerkmale

Quellmerkmale Zielmerkmale Kommentar

0CALDAY, 0FISCVARNT 0FISCPER Geschäftsjahresvariante wird benötigt

0CALDAY, 0FISCVARNT 0FISCYEAR Geschäftsjahresvariante wird benötigt

0CALDAY, 0FISCVARNT 0FISCPER3 Geschäftsjahresvariante wird benötigt

0FISCPER, 0FISCVARNT 0FISCYEAR Geschäftsjahresvariante wird benötigt

0FISCPER, 0FISCVARNT 0FISCPER3 Geschäftsjahresvariante wird benötigt

0CALWEEK, 0WEEKDAY1 0CALDAY

0CALYEAR, 0CALQUART1 0CALQUARTER

0CALYEAR, 0CALMONTH2 0CALMONTH

0FISCYEAR, 0FISCVARNT, 0FISCPER3 0FISCPER Geschäftsjahresvariante wird benötigt

0FISCVARNT, 0FISCYEAR, 0FISCPER3 Geschäftsjahresvariante wird benötigt

Es gibt zwei Typen von Datenscheiben:

Grundsätzlich gelten für Datenscheiben die folgenden Regeln:

Datenscheibe anlegen [Seite 180]

1.2.4 Merkmalsbeziehungen und Datenscheiben auf der SAP

R_01 RP_123 UP_123

R_02 RP_123 UP_321

In den regional verschiedenen Vertriebsorganisationen können verschiedene Produkte dieselbe

Implementierung auf der SAP HANA-Datenbank

Im Falle einer SQLScript-Implementierung werden die Namen der implementierenden SQLScript-

Für die ABAP-Verarbeitung der Exits werden folgende Schnittstellen benötigt:

● IF_RSPLS_CR_EXIT : ABAP-Implementierung der Merkmalsbeziehungen

● IF_RSPLS_CR_EXIT_HDB : SQLScript-Implementierung der Merkmalsbeziehungen

Die SAP HANA-spezifischen Schnittstellen haben folgende Aufgaben:

SAP HANA-spezifische Schnittstellen für Merkmalsbeziehungen und Datenscheiben [Seite 19]

1.2.4.1 SAP HANA-spezifische Schnittstellen für

Die Methode GET_SQLSCRIPT_INFO der Schnittstelle IF_RSPLS_CR_EXIT_HDB hat folgende

Exportparameter der Methode GET_SQLSCRIPT_INFO des IF_RSPLS_CR_EXIT_HDB

E_DB_SCHEMA_NAME Name eines Datenbank-Schemas, das die auszuführenden

Wenn der Parameter von der Methode nicht gesetzt wird,

E_PROCEDURE_NAME_CHECK Name der SQLScript-Procedure, die die Implementierung

E_PROCEDURE_NAME_DERIVE Name der SQLScript-Procedure, die die Implementierung

E_PROCEDURE_NAME_CREATE Name der SQLScript-Procedure, die die Implementierung

E_PARAMETER_NAME Name einer DDIC-Struktur, die zusätzliche Parameter be­

Wenn der Parameter von der Methode nicht gesetzt wird,

Exportparameter der Methode GET_SQLSCRIPT_INFO des IF_RSPLS_DS_EXIT_HDB

E_DB_SCHEMA_NAME Name eines Datenbank-Schemas, das die auszuführenden

Wenn der Parameter von der Methode nicht gesetzt wird,

E_PROCEDURE_NAME_PROTECTED Name der SQLScript-Procedure, die die Implementierung

E_PARAMETER_NAME Name einer DDIC-Struktur, die zusätzliche Parameter be­

E_PARAMETER_NAME Name einer DDIC-Struktur, die zusätzliche Parameter be

E_PARAMETER_NAME Name einer DDIC-Struktur, die zusätzliche Parameter be

E_S_PARAMETER Struktur, um zusätzliche Parameter an die SQLScript-Proce

Zur Laufzeit hat dieser Parameter den Typ der DDIC-Struk

Queries (insbesondere eingabebereite Queries) ● für die Parametrisierung von Merkmalseinschränkun

Beim Starten einer Query können Variablen durch einen vor

Es ist nicht möglich, durch eine Änderung von Variablen Da

Filter und Planungsfunktion innerhalb einer Planungsse ja

Datenscheibe oder Merkmalsbeziehung mit beliebigem an nein