In diesem Artikel geht es um die Verwendung des Custom Operators in der Hybridplanung als nützliches Werkzeug, um das (unbeabsichtigte) Löschen von Vorbelegungen beim Splashing zu vermeiden.
Beim Planen in DeltaMaster ist es üblich, dass die Planwerte nicht auf den Basiselementen eingegeben werden, sondern auf höheren Ebenen, z. B. Jahr, Produktgruppe oder Region. Dies ist der Tatsache geschuldet, dass ansonsten schnell ein großer Datenraum entsteht, der einzeln bearbeitet werden muss.
In diesem Artikel behandeln wir ein Beispiel mit 12 Monaten, 22 Produkten und 61 Kunden – und damit gut 16.000 möglichen Kombinationen. Natürlich kauft nicht jeder Kunde in jedem Monat alle Produkte, aber eine systemische Unterstützung für sinnvolle Kombinationen und realistische Verteilung von höheren Ebenen ist unbedingt notwendig.
Welcher Kunde bereits welche Produkte wann gekauft hat, wissen wir aus der Vergangenheit. Deshalb empfehlen wir in Planungsprojekten eine Vorbelegung der Planung mit Daten aus der Vergangenheit, die gegebenenfalls um einen variablen Faktor angepasst wird (beispielweise 6 % mehr Absatz oder 5 % weniger Kosten). Damit haben wir eine valide Vorbelegung.
Bei der Eingabe von Werten auf höheren Ebenen einer oder mehrerer Dimensionen (Splashing) kann DeltaMaster diese Werte sinnvoll anhand der prozentualen Anteile der vorbelegten Basiselemente verteilen. Wird diese intelligente Vorbelegung allerdings gelöscht durch Eingabe von Null oder Entfernen, ist rein mathematisch nur eine Gleichverteilung auf alle Basiselemente oder Kopieren des Wertes auf alle Basiselemente möglich.
Dieses Löschen auf höherer Ebene wollen wir abfangen und nur über einen speziellen Operator zulassen.
Ausgangssituation
Wir nehmen als Basis die Vertriebsplanung aus unserer Muster-Datenbank, der fiktiven Chair AG.
Die Dimensionen haben mehrere Ebenen (Level). Um die Planung zu vereinfachen, wird zunächst nur der Monatswert pro Kunde auf der Ebene Produktgruppe eingegeben.
Diese Summe soll anhand der prozentualen Anteile auf die einzelnen Monate und die Produkte verteilt werden. In unserem Beispiel werden diese Anteile errechnet, indem der jeweilige Monatswert durch die Summe der Absätze des letzten Jahres aus dem Ist geteilt wird.
Custom Operator als Universalwerkzeug
Die Technik der Hybrid- oder Delta-Hybrid-Planung enthält über den Aufbau mit DeltaMaster ETL unter anderem automatisch die drei WriteBack-Prozeduren pro rückschreibefähiger Measuregroup.
P_WriteBackSQL_FACT_01_Vertriebsplanung
@TransactionID = '70c59265-a532-4791-9fd6-9fbbac6a9d98',
@UserName = N'BISSANTZ\..',
@MeasureName = N'Absatz',
@MeasureValue = 0,
@MeasureValueOld = 24,
@Operator = N'=',
@MeasureValueOldType = 0,
@CustomOperator = N'd',
@Kumulation_Kumulation_AttrName = N'KumulationID',
@Kumulation_Kumulation_MemberKey = N'1',
@Kunde_Kunde_AttrName = N'KundeID',
@Kunde_Kunde_MemberKey = N'Geo47',
@Periode_Periode_AttrName = N'MonatID',
@Periode_Periode_MemberKey = N'202202',
@Periodenansicht_Periodenansicht_AttrName = N'PeriodenansichtID',
@Periodenansicht_Periodenansicht_MemberKey = N'1',
@Produkt_Produkt_AttrName = N'ProduktgruppeID',
@Produkt_Produkt_MemberKey = N'1',
@Wertart_Wertart_AttrName = N'WertartID',
@Wertart_Wertart_MemberKey = N'P',
@ErrorDesc = NULL,
@ReturnValue = 0
An diese Prozeduren werden bei jedem Schreibvorgang von DeltaMaster Parameter übergeben. Die Übergabeparameter werden in der Log-Datei „sql.log“ protokolliert.
Für uns sind die Zeilen mit dem Suffix „_AttrName“ (z. B. @Periode_Periode_AttrName) wichtig, da hier das Level der Dimension mitgegeben wird. Dadurch können wir die Eingabe auf Basisebene oder Verdichtung unterscheiden.
Der in diesem Fall nächste wichtige Parameter ist der Custom Operator, der mit dem Erkennungszeichen „#“ bei der Eingabe beginnt, gefolgt von einer beliebigen Zeichenfolge. Im sql.log wird „#“ weggelassen, da das Erkennungszeichen nur dazu dient, DeltaMaster zu signalisieren, dass der Custom Operator zusätzlich an die Prozedur übergeben werden soll. Näheres findet sich z. B. im Blog „Wertfortschreibung in der Hybridplanung per Custom Operator“.
Wir definieren einen neuen Custom Operator „0#d“ zum expliziten Löschen von Werten auf aggregierten Ebenen. Auf Basisebene lassen wir nach wie vor die Eingabe von „0“ zu.
IF @MeasureValue IS NULL OR @MeasureValue = 0
BEGIN
-- Prüfung auf Basis Ebene
IF
@Kumulation_Kumulation_AttrName = N'KumulationID'
AND
@Kunde_Kunde_AttrName = N'KundeID'
AND
@Periode_Periode_AttrName = N'MonatID'
AND
@Periodenansicht_Periodenansicht_AttrName = N'PeriodenansichtID'
AND
@Produkt_Produkt_AttrName = N'ProduktID'
AND
@Wertart_Wertart_AttrName = N'WertartID'
BEGIN
SET @MeasureValue = 0
END
ELSE
BEGIN
IF LOWER(@CustomOperator) = 'd'
BEGIN
SET @MeasureValue = 0
END
ELSE
BEGIN
RAISERROR('Löschen von Daten auf verdichteter Ebene nur über Operator 0#d möglich!', 16, 1)
SET @StopWriteBack = 1
END
END
END
Nun müssen wir im PreProcess eine Sonderbehandlung von „0“ und „Null“ einbauen. Auf Basisebene soll der Wert einfach weitergeben werden, auf verdichteter Ebene soll ein Hinweis erscheinen.
Eingabe in DeltaMaster
In der Eingabeanwendung können auf beliebigen Ebenen Daten eingegeben werden. Wir bleiben in dem Beispiel bei Kunde, Monat und Produkt/Produktgruppe.
Zunächst geben wir eine 0 auf Basisebene ein und der Wert wird geschrieben.
Als nächstes versuchen wir die 0 auf einer höheren Ebene einzugeben. Dies wird entsprechend abgefangen (vgl. Abbildung 6).
Die Möglichkeiten, die sich über das Feature Custom Operator ergeben, sind sehr vielfältig und werden vom Bissantz-Team bereits ausgiebig genutzt. Dazu zählen z. B. beliebige Vorbelegungen/Verteilungen (SplashLike) oder Fortschreibung eines Wertes über die Zeit.