Dieser Blogbeitrag behandelt die Probleme von Währungsumrechnung und Vorschlagswerten im Umfeld der Delta-Hybrid-Planung. Es werden möglichst allgemeingültige Lösungen für diese Probleme aufgezeigt, indem unterschiedliche Lösungsansätze diskutiert werden. Außerdem werden Codebeispiele für die Währungsumrechnung und eine Prozessbeschreibung für die korrekte Aufbereitung von Vorschlagswerten geliefert.

Das Delta im Vorschlag

Einleitung

Seit letztem Jahr wird die Technologie der Delta-Hybrid-Planung produktiv in Kundenprojekten genutzt. Delta-Hybrid bietet neben großen Performancevorteilen durch die Delta-Logik an vielen Stellen die Möglichkeit eingegebene Werte zu überprüfen, weiterzuleiten und zu manipulieren. Grundlegende Kenntnisse zur Delta-Hybrid-Technologie werden in diesem Blogbeitrag vorausgesetzt.

Eine Form der Datentransformation, die häufig bei der Planung monetärer Kennzahlen vom Kunden gefordert wird, ist die Währungsumrechnung. Man gibt einen Wert ein, der an die Datenbank weitergegeben und dort mit Hilfe weniger Zeilen SQL von einer Währung in eine andere Währung umgerechnet wird. Die häufig gewünschten und beliebten Vorschlagswerte für die Planeingaben erhöhen die Komplexität zusätzlich.

Mit den Stolpersteinen, die hierbei umschifft werden müssen, und Lösungswegen für eine möglichst stressfreie und übersichtliche Implementierung wird sich dieser Blogartikel befassen.

Vorstellung des Problems

Am Anfang steht zunächst häufig die Frage, welche Stelle sich am besten dafür anbietet, die Währungsumrechnung vorzunehmen. Eine weitere Hürde für die Währungsumrechnung in einer DeltaHybrid-Planung stellen Vorschlagswerte dar, da der Wert, der im DeltaMaster angezeigt wird, sich möglicherweise aus Werten aus zwei Tabellen zusammensetzt oder auf Vorschlägen aus einer alten Planungsrunde basiert. Dies soll im Folgenden an einem kleinen Beispiel vorgestellt werden:

Es handelt von einer rollierenden Planung, bei der die Planwerte der letzten Planungsrunde als Vorschlagswerte der aktuellen Runde genutzt werden sollen. Die Vorschlagswerte müssen zu Beginn einer jeden Planungsrunde in der T_WritebackSQL_FACT-Tabelle (im weiteren Writeback-Tabelle) stehen. Auf Grund der Delta-Logik in der Rückschreibprozedur, die eingegebene Werte auf ein Delta zu Werten in der Writeback-Tabelle oder der T_ WritebackSQL_FACT_DELTA-Tabelle (im weiterem Delta-Tabelle) prüft, dürfen die Vorschlagswerte nicht in der eigentlichen Faktentabelle des Modells vorgehalten werden. Würden die Vorschlagswerte an dieser Stelle vorgehalten werden, werden keine Werte in die Datenbank zurückgeschrieben, da die Rückschreibprozedur in einen Fehler läuft.

Zu Beginn zeigt der Planungsbericht einen Vorschlagswert von 1000€ an. Dieser soll auf 1200€ erhöht werden. Parallel soll der Planwert für die Konzernmutter in Dollar umgerechnet werden. Der Wechselkurs wird in einer Steuertabelle vorgehalten und beträgt aktuell 1,00€ zu 1,20$. In dem Kontrollbericht, der die Dollarwerte präsentiert, werden nach der Eingabe entsprechend 1440$ erwartet. Dieser Wert wird auch angezeigt, wenn der Vorschlagswert auf demselben Wechselkurs beruht. Im Normalfall ändern sich bei einer rollierenden Planung aber auch die Wechselkurse von einer Planungsrunde zur anderen.

In diesem Beispiel nehmen wir einen Kurs von 1,00€ zu 1,18$ für die vorherige Planungsrunde an. Der untenstehenden Tabelle kann entnommen werden, dass das Ergebnis nicht der Erwartung entspricht, wenn die auf den alten Wechselkursen basierenden Planwerte verwendet werden.

Tabelle 1 – Beispiel der Währungsumrechnung

Der Grund hierfür liegt an der Delta-Logik. Sobald die Eingabe der 1200€ an die Datenbank zurückgegeben wird, prüft die Rückschreibprozedur, ob bereits in der Writeback- und/oder der Delta-Tabelle Werte für diese Zelle vorhanden sind. Stehen in der Writeback-Tabelle Werte, wird ein Delta gebildet und dieser Delta-Wert in die Delta-Tabelle geschrieben. Wenn nur in der Delta-Tabelle ein Wert vorhanden ist, wird dieser mit dem eingegebenen Wert überschrieben. Liegt in beiden Tabellen noch kein Wert für die Zelle vor (Eingabe in leere Zelle), wird der Wert als Ganzes zurückgeschrieben.

In dem Beispiel werden also nur 200€ zurückgeschrieben. Diese, mit dem Wechselkurs der aktuellen Planungsrunde umgerechnet, ergeben 240$. Aus rein technischer Sicht, ist dies ein logisches und auch korrektes Verhalten. Da im Zusammenhang mit dem auf dem alten Wechselkurs basierenden Vorschlagswert ein falsches Ergebnis in Summe im Kontrollbericht erscheint, ist es in der Praxis für den User nur schwer nachvollziehbar, wie dieser Fehler zustande kommt.

Bei Nutzung der Hybrid-Planung ohne die Delta-Technologie würde dieses Problem nicht auftreten, Jedoch geht hierdurch der Performancevorteil bei großen Datenmengen verloren. Gerade durch die Währungsumrechnung wird der Datenbestand je nach Anzahl der Umrechnungen vervielfacht, wodurch bei einer größeren Anzahl Planern schnell eine kritische Datenmenge erreicht wird und die Anwendung spürbar langsamer wird. Es gilt also genau abzuwägen, welcher Ansatz verwendet wird. Wird sich für den Delta-Hybrid-Ansatz entschieden, müssen gewisse Punkte für die Währungsumrechnung und die Handhabung der Vorschlagswerte berücksichtigt werden. Lösungsansätze für dieses Problem werden im nächsten Kapitel vorgestellt.

Vorstellung der Lösungsansätze

Generelle Möglichkeiten zur Währungsumrechnung

Zunächst muss entschieden werden, an welcher Stelle die Währungsumrechnung erfolgen soll. Hier gibt es zwei Möglichkeiten. Zum einen kann sie mit der Eingabe (direkt) erfolgen, sodass mit Eingabe eines Wertes auch der umgerechnete Wert zurückgeschrieben wird. Zum anderen können die Werte (indirekt) am Ende eines Tages oder wenn die Planungsrunde abgeschlossen wurde in einem Prozess umgerechnet werden.

Eine Umrechnung direkt mit der Eingabe ist die Vorgehensweise, die für das oben beschriebene Beispiel angenommen wurde. Der Vorteil dieser ist, dass auch die umgerechneten Werte sofort zur Verfügung stehen. So können zum Beispiel von einem Vorgesetzten direkt alle Planeingaben in einer einheitlichen Währung konsolidiert betrachtet werden. Außerdem müssen nie mehr als nur ein paar Werte auf einmal umgerechnet werden, sodass der User den Prozess der Umrechnung im Idealfall gar nicht erst wahrnimmt. Für die direkte Umrechnung der eingegebenen Werte gibt es zwei durchaus praktikable Lösungsansätze. Bei dem ersten wird mit dem Moment der Eingabe der zurückgeschriebene Wert direkt umgerechnet, bei der zweiten Variante werden alle während einer Transaktion eingegebenen Werte auf einmal umgerechnet, sobald die Transaktion bestätigt wurde.

In der ersten Variante wird die P_Writeback_PostProcess-Prozedur (im weiteren PostWriteback-Prozedur) genutzt. Sie wird innerhalb der Rückschreibprozedur aufgerufen, nachdem der ursprünglich eingegebene Wert in die Delta-Tabelle geschrieben wurde und enthält alle Parameter, die auch mit der Eingabe an die Rückschreibprozedur übergeben wurden. In der PostWriteback-Prozedur wird nun der eingegebene Wert umgerechnet und im Anschluss wieder die Rückschreibprozedur aufgerufen. Beim Aufruf dieser müssen lediglich die Parameter für die Währung und für den zurückzuschreibenden Wert mit dem Ergebnis der Währungsumrechnung belegt werden. Außerdem muss eine Abbruchbedingung festgelegt werden, da ansonsten immer wieder die Rückschreibprozedur aufgerufen wird, wodurch eine Endlosschleife erzeugt wird. Hierfür empfiehlt sich der Parameter @SourceID, der einfach mit einer neuen ID belegt werden kann, deren Bedeutung in der Tabelle T_MODELSYS_WriteDataSource eingepflegt werden sollte. Ein einfaches Beispiel für die PostWriteback-Prozedur könnte wie folgt aussehen:

DECLARE @ErrorDesc varchar(255)
DECLARE @MeasureValueOldType bit
DECLARE @ExchangeRate float = NULL
SET @MeasureValueOldType = 1 
-- Prüfen des Wertes von @SourceID -> Bei initialem Aufruf ist der Wert NULL, danach >= 4
SET @SourceID = isnull(@SourceID, 4)
-- Umrechnung LC zu GC
IF @Currency_Currency_MemberKey = 'LC' AND @SourceID = 4 BEGIN
-- Variable @ExchangeRate korrekten Kurs zuweisen 
SET @ExchangeRate = (
SELECT 
xr.ExchangeRate
--select * 
FROM
T_S_ExchangeRate xr 
WHERE
Seite 6 von 9
xr.MonthID = @Periode_Periode_MemberKey 
)

-- Operator '=' bedeutet, dass Wert in leere Zelle geschrieben wurde; Operator '*', dass 
sich der Wert einer gefüllten Zelle ändert
IF @Operator = '='
SET @MeasureValue = @MeasureValue * @ExchangeRate 
IF @Operator = '*'
SET @MeasureValueOld = @MeasureValueOld * @ExchangeRate 
-- Anpassen von CurrencyID und SourceID
SET @Currency_Currency_MemberKey = 'GC'
SET @SourceID = 5 
-- Aufruf der Prozedur [P_WriteBackSQL_FACT_01_Sales] mit geänderten Parametern 
EXECUTE [dbo].[P_WriteBackSQL_FACT_01_Deckungsbeitragsrechnung] 
@TransactionID 
 ,@Username 
 ,@MeasureName 
 ,@MeasureValue 
 ,@MeasureValueOld 
 ,@ErrorDesc OUTPUT 
 ,@Operator 
 ,@MeasureValueOldType 
 ,@Periode_Periode_AttrName 
 ,@Periode_Periode_MemberKey 
 ,@Wertart_Wertart_AttrName 
 ,@Wertart_Wertart_MemberKey 
 ,@Periodenansicht_Periodenansicht_AttrName 
 ,@Periodenansicht_Periodenansicht_MemberKey 
 ,@Kumulation_Kumulation_AttrName 
 ,@Kumulation_Kumulation_MemberKey 
 ,@Kunde_Kunde_AttrName 
 ,@Kunde_Kunde_MemberKey 
 ,@Kunde_Branche_AttrName 
 ,@Kunde_Branche_MemberKey 
 ,@Produkt_Produkt_AttrName 
 ,@Produkt_Produkt_MemberKey 
 ,@Stoffgruppe_Stoffgruppe_AttrName 
 ,@Stoffgruppe_Stoffgruppe_MemberKey 
 ,@Vertrieb_Vertrieb_AttrName 
 ,@Vertrieb_Vertrieb_MemberKey 
 ,@Einheit_Einheit_AttrName 
 ,@Einheit_Einheit_MemberKey 
 ,@Currency_Currency_AttrName 
 ,@Currency_Currency_MemberKey 
 ,@SourceID OUTPUT
 ,@LogLevel 
 ,@LogLevelActionDetail = 0 
RETURN END

Der große Vorteil des wiederholten Aufrufens der Rückschreibprozedur ist, dass bis zur Bestätigung der Eingabe der alte Stand in der Rollback-Tabelle vorgehalten wird und sich einfach der Mittel, die ohnehin schon vorhanden sind, bedient wird. Es muss also keine komplexe Rückschreiblogik entwickelt werden.

Für die zweite Variante wird die P_WritebackSQL_Commit_PostProcess-Prozedur (im weiteren PostCommit-Prozedur) genutzt. An diese werden im Gegensatz zur PostWriteback-Prozedur nicht sämtliche Informationen zu den Dimensionseigenschaften und dem eingegebenen Wert als Parameter mit gegeben, sondern lediglich die TransaktionsID der jeweiligen Transaktion, die mit dem Commit bestätigt und abgeschlossen wird. Die TransaktionsID steht in der Delta-Tabelle, weshalb über diese im PostCommit auf die während der Transaktion zurückgeschriebenen Datensätze zugegriffen werden kann.

Zunächst wird eine temporäre Tabelle erstellt, die mit den Zeilen der Delta-Tabelle gefüllt wird, die in der geschlossenen Transaktion eingefügt bzw. geändert wurden. Diese temporäre Tabelle dient bei einem anschließenden Merge mit der Delta-Tabelle als Quelle. Für den Fall, dass für die Zelle in der Delta-Tabelle bereits ein Datensatz existiert, wird ein Update-Statement auf die Kennzahl und die für das Logging benötigten Spalten ausgeführt. Existieren noch keine Datensätze in der Delta-Tabelle, werden diese mit sämtlichen Informationen über ein Insert-Statement angelegt. Da das SQL-Statement für diese Prozedur deutlich über 100 Zeilen lang ist, wird an dieser Stelle darauf verzichtet, es in den Text einzubetten. Die Datei PostCommit_EineKennzahl.sql im Ordner dieses Blogs enthält aber das gesamte Statement.

Die Vorteile der PostProcess-Prozedur sind hier natürlich nicht gegeben, jedoch wird auch keine Logik für das Rollback benötigt, da an dieser Stelle die Eingaben bestätigt werden und der User festlegt, dass sie übernommen werden. Der große Vorteil dieser Variante ist, dass sie keinerlei Auswirkung auf die Performance der Eingabe selber hat. Nur das Bestätigen der Eingabe wird ggf. etwas verlängert, wenn viele Eingaben während einer Transaktion getätigt wurden. Nachteilig an dieser Variante ist jedoch, dass das Erstellen der Prozedur deutlich aufwendiger ist. Es muss auch berücksichtigt werden, dass wirklich alle Dimensionsspalten als Schlüsselkriterium für den Merge verwendet werden. Hinzu kommt die steigende Komplexität, wenn nicht nur eine Kennzahl, sondern mehrere Kennzahlen (z.B. Umsatz und Gewinn) in einer Anwendung beplant werden und sich in einer Measuregruppe befinden. Dann nämlich wird dieselbe PostCommit-Prozedur verwendet. Die Prozedur muss dynamisch gestaltet werden, damit sie für eben die Kennzahl ausgeführt wird, die in der Transaktion beschrieben wurde. Eine reine Überprüfung der Schlüsselkriterien genügt hier nicht mehr. Die Überprüfung, welche Kennzahl beplant wurde, lässt sich auch mit Hilfe der TransaktionsID durchführen. Über diese kann in der Tabelle T_SYSLOG_WritebackSQL, die in der Transaktion beplante Kennzahl bestimmt werden. Anschließend wird der gleiche Prozess durchlaufen, wie bei nur einer Kennzahl. Die Datei PostCommit_BeliebigVieleKennzahlen.sql enthält das komplette Statement. Zu erwähnen bleibt, dass diese Lösung nur funktioniert, wenn nur eine Kennzahl in einem Bericht, sprich während einer Transaktion, beplant wird. Sollten in einem Bericht mehrere Kennzahlen beplant werden, erhöht sich die Komplexität nochmals, da hier eine zusätzliche Schleife um das Statement gebaut werden muss. Diese Schleife durchläuft den Prozess dann zunächst für die eine und anschließend die andere Kennzahl. Dies soll aber nicht Bestandteil dieses Blogs sein.

Es gibt also zwei praktikable Lösungen für die Durchführung der Währungsumrechnung von Planeingaben bei der Delta-Hybrid-Planung. Welche dieser Lösungen verwendet wird, muss wie so oft individuell entschieden werden. Wenn der umgerechnete Wert sofort in demselben Planungsbericht ersichtlich sein soll, muss auf die erste Lösung in der PostWriteback-Prozedur zurückgegriffen werden. Diese lässt sich auch schneller und einfacher umsetzen. Dafür wird mit jeder Eingabe eine Umrechnung durchgeführt, was bei einer gut gefüllten Delta-Tabelle durchaus für kleine Performanceeinbußen sorgen kann. Die Verwendung der PostCommit-Prozedur stellt eindeutig die aufwendigere Lösung dar, hat aber den Vorteil, dass nur einmal alle Eingaben einer Transaktion umgerechnet werden und nur beim Bestätigen dieser gewartet werden muss. Da der erhöhte Aufwand aber nur einmalig notwendig ist, ist auch diese Vorgehensweise gerade bei Projekten, bei denen viele Einträge in die Delta-Tabelle geschrieben werden und mehrere Eingaben in einem Bericht erfolgen, nicht zu verachten.

Verwendung von Vorschlagswerten

Selbstverständlich müssen Vorschlagswerte, wenn sie genutzt werden, im Prozess der Währungsumrechnung berücksichtigt werden, wie das bereits vorgestellte Beispiel dargelegt hat. In der Regel werden Vorschlagswerte aus den Werten einer vorherigen Planungsrunde übernommen, um nicht wieder komplett bei null in der neuen Planung anzufangen.

Bevor nun überlegt wird, an welcher Stelle im Prozess diese Berücksichtigung vorgenommen werden soll, muss festgelegt werden, welche Werte überhaupt umgerechnet werden sollen. Sollen nur Eingaben umgerechnet werden oder auch Vorschlagswerte, die ohne eine Änderung übernommen werden? Das erste Kriterium, das an dieser Stelle geprüft werden muss, ist die Herkunft der Vorschlagswerte. Da im Normalfall mit jeder Planungsrunde die Umrechnungskurse angepasst werden, sollten auch die Vorschlagswerte auf den aktuellen Kursen beruhen. Dies mag auf den ersten Blick ziemlich trivial wirken, ganz so einfach ist es aber nicht und Bedarf einer eindeutigen Abstimmung im Projektteam.

Zunächst ist wichtig, dass die Vorschlagswerte sowohl in der Währung, in der die Eingabe erfolgen soll, vorliegen muss, als auch in allen Währungen, in denen die Eingabe umgerechnet werden soll. Ferner ist wichtig festzulegen, was mit Vorschlägen geschieht, die ohne eine Änderung übernommen werden. Basieren die Vorschläge zum Beispiel auf den Einträgen der letzten Planungsrunde und wurden im Vorfeld der nächsten Runde nicht modifiziert, würde eine Übernahme des Vorschlags erstmal bedeuten, dass auch der Wert in der anderen Währung übernommen wird, der aber noch auf dem Wechselkurs der vorherigen Runde beruht. Somit ist zumindest der umgerechnete Wert faktisch nicht korrekt. Dieser Fehler fällt im Zweifel niemandem auf, da sich beide Werte nicht ändern. Jedoch entsprechen 1 Mio. Euro in dem einem Monat 1,195 Mio. Dollar und im nächsten vielleicht 1,2 Mio. Dollar, weshalb die Verhältnisse nicht mehr korrekt sind.

Ein weiteres Problem, wenn die Vorschläge auf veralteten Kursen beruhen, ist, dass bloß die Differenz zwischen Vorschlag und Eingabe umgerechnet wird. Beruhen beide Werte jedoch auf demselben Kurs, kann dies bedenkenlos hingenommen werden. Es kann zwar über die Informationen zu den Dimensionselementen der entsprechende Wert aus der Writeback-Tabelle herangezogen werden, was ermöglicht, den korrekten Delta-Wert für die umgerechneten Währungen zu beschaffen.

Ein großer Vorteil dieser Vorgehensweise ist, dass so bedenkenlos die im vorherigen Kapitel vorgestellten Methoden zur Währungsumrechnung für die Eingaben genutzt werden können. Ferner ist die Umsetzung dieser initialen Vorbereitung recht simpel und lässt sich ohne größeren Aufwand in jeden Prozess zur Einrichtung einer neuen Planungsrunde integrieren. Nachdem über die P_WritebackSQL_Consolidate-Prozedur alle Einträge der Delta-Tabelle mit denen der Writeback-Tabelle zusammengefasst wurden, enthält die Writeback-Tabelle für jede Kombination von Dimensionselementen, die beplant wurde nur noch ein Datensatz. Zum einen stehen diese Werte nun für den Export und die weitere Verwendung von Planwerten zur Verfügung, zum anderen können so die Zeilen, die Planwerte in Konzernwährung oder der jeweiligen lokalen Währungen enthalten, herausgefiltert werden. Diese können dann in die jeweils andere Währung mit den aktualisierten Kursen für die nächste Planungsrunde umgerechnet werden. Sofern keine weiteren Prozessschritte beachtet werden müssen, genügt hier eine ganz einfache Währungsumrechnung, wie sie auch in vorherigen Blogartikeln beschrieben wurde. Anschließend müssen die für die neue Planungsrunde vorbereiteten Daten nur noch in die Writeback-Tabelle geschrieben werden. Diese enthält zu diesem Zeitpunkt idealerweise keine Stände aus der vorhergegangenen Planungsrunde mehr.

Fazit

Wie so oft muss zu allererst gesagt werden, dass Planung immer eine höchstindividuelle Angelegenheit ist, weshalb auch vermeintliche Standardprozesse wie Währungsumrechnung nicht immer ohne weiteres zu implementieren sind. Dennoch sind die Probleme, die hierbei auftreten, meistens die gleichen. Auf die grundlegenden Probleme und auch die zusätzliche Komplexität, die durch die Verwendung von Vorschlagswerte gerade beim Einsatz der Delta-Hybrid-Technologie entsteht, hat dieser Blogbeitrag dennoch hingewiesen und Lösungsvorschläge geliefert.

Wenn Vorschlagswerte verwendet werden, lässt sich ganz einfach sagen, dass es zu empfehlen ist, diese zu Beginn einer neuen Planungsrunde in allen verwendeten Währungen in der Writeback-Tabelle vorzuhalten. Hierbei ist zwingend erforderlich, dass die Umrechnung mit den Kursen stattzufinden hat, die in der neuen Planungsrunde genutzt werden.

Welcher der beiden vorgestellten Ansätze für die Währungsumrechnung verfolgt wird, hängt letzten Endes davon ab, ob und wenn ja wofür die PostWriteback- und die PostCommit-Prozedur noch genutzt werden und ob sich eine Umrechnung in diese integrieren lässt. Außerdem ist entscheidend, wie aufwendig die Erstellung der Prozedur für das PostCommit bei dem in der Planung verwendeten Modell ist. Wenn von den beiden genannten Punkten keiner gegen die PostCommit-Prozedur spricht, ist in Erwägung zu ziehen, ob sich der Mehraufwand nicht lohnt, da hier nur einmal alle Einträge einer Transaktion gesammelt umgerechnet werden und nicht alle Einträge einzeln mit der Eingabe.