CiAgICA8IS0tIExpbmtlZEluIC0tPgogICAgPHNjcmlwdCB0eXBlPSJ0ZXh0L2phdmFzY3JpcHQiPgogICAgICAgIF9saW5rZWRpbl9wYXJ0bmVyX2lkID0gIjEyMzUwNzMiOwogICAgICAgIHdpbmRvdy5fbGlua2VkaW5fZGF0YV9wYXJ0bmVyX2lkcyA9IHdpbmRvdy5fbGlua2VkaW5fZGF0YV9wYXJ0bmVyX2lkcyB8fCBbXTsKICAgICAgICB3aW5kb3cuX2xpbmtlZGluX2RhdGFfcGFydG5lcl9pZHMucHVzaChfbGlua2VkaW5fcGFydG5lcl9pZCk7CiAgICA8L3NjcmlwdD48c2NyaXB0IHR5cGU9InRleHQvamF2YXNjcmlwdCI+CiAgICAgICAgKGZ1bmN0aW9uKCl7dmFyIHMgPSBkb2N1bWVudC5nZXRFbGVtZW50c0J5VGFnTmFtZSgic2NyaXB0IilbMF07CiAgICAgICAgICAgIHZhciBiID0gZG9jdW1lbnQuY3JlYXRlRWxlbWVudCgic2NyaXB0Iik7CiAgICAgICAgICAgIGIudHlwZSA9ICJ0ZXh0L2phdmFzY3JpcHQiO2IuYXN5bmMgPSB0cnVlOwogICAgICAgICAgICBiLnNyYyA9ICJodHRwczovL3NuYXAubGljZG4uY29tL2xpLmxtcy1hbmFseXRpY3MvaW5zaWdodC5taW4uanMiOwogICAgICAgICAgICBzLnBhcmVudE5vZGUuaW5zZXJ0QmVmb3JlKGIsIHMpO30pKCk7CiAgICA8L3NjcmlwdD4KICAgIDxub3NjcmlwdD4KICAgICAgICA8aW1nIGhlaWdodD0iMSIgd2lkdGg9IjEiIHN0eWxlPSJkaXNwbGF5Om5vbmU7IiBhbHQ9IiIgc3JjPSJodHRwczovL3B4LmFkcy5saW5rZWRpbi5jb20vY29sbGVjdC8/cGlkPTEyMzUwNzMmZm10PWdpZiIgLz4KICAgIDwvbm9zY3JpcHQ+CiAgICA8IS0tIEVuZCBMaW5rZWRJbiAtLT4KICAgIA==
Generic filters
Exact matches only
Search in title
Search in excerpt
Search in content

Splashing mit Rückversicherung

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.

Measure-Gruppe Vertriebsplanung

Abbildung 1: Measure-Gruppe Vertriebsplanung

Die Dimensionen haben mehrere Ebenen (Level). Um die Planung zu vereinfachen, wird zunächst nur der Monatswert pro Kunde auf der Ebene Produktgruppe eingegeben.

Levels

Abbildung 2: Levels

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.

WriteBack-Prozeduren

Abbildung 3: WriteBack-Prozeduren

 

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.

Eingabe im DeltaMaster

Abbildung 4: Eingabe im DeltaMaster

Zunächst geben wir eine 0 auf Basisebene ein und der Wert wird geschrieben.

Eingabe auf Basisebene

Abbildung 5: Eingabe auf Basisebene

Als nächstes versuchen wir die 0 auf einer höheren Ebene einzugeben. Dies wird entsprechend abgefangen (vgl. Abbildung 6).

Eingabe auf nicht Basisebene Arcade mit Hinweis

Abbildung 6: Eingabe auf nicht Basisebene Arcade mit Hinweis

ingabe nicht Basisebene Arcade

Abbildung 7: Eingabe auf nicht Basisebene Arcade mit Custom Operator und erfolgreichem Löschen

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.