Die dritte Zielsetzung dieser Arbeit ist die Implementierung des Preissetzungsansatzes, der im Rahmen der theoretischen Ausarbeitung ausgewählt wurde. Es soll folglich ein Prozess implementiert werden, der die empfohlenen Normalpreise für die Eckartikel auf Basis der beschafften Konkurrenzpreise automatisiert berechnet. Die empfohlenen Nor-malpreise können anschließend in einem Niedrigpreisprogramm verwendet werden.
Im ersten Unterkapitel wird erläutert, wie die konkreten Preissetzungsempfehlungen als Daten so auf- und vorbereitet werden können, dass sie zur Geschäftszeit performant abgerufen werden können. Im zweiten Unterkapitel wird erläutert, wie die Datensätze in der PREISAKTIONEN-Datenbanktabelle, die sich auf einen bestimmten Eckartikel be-ziehen, so transformiert werden können, dass sie bei der anschließenden Berechnung des empfohlenen Normalpreises performant und einheitlich abgerufen werden können. Im dritten Unterkapitel wird schließlich erläutert, wie der Prozess implementiert werden kann, die konkreten Preisempfehlungen für die einzelnen Artikel auf Basis der transfor-mierten Daten der PREISAKTIONEN-Tabelle automatisiert zu berechnen. Es müssen da-bei die Preissetzungsstrategie des Unterbietens und des Haltens des Wettbewerbs dif-ferenziert werden.
Neue Datenbanktabelle für die empfohlenen Normalpreise
Weil eine hohe Anzahl von Artikelpreisen performant gesetzt werden soll, erscheint es nicht sinnvoll, die empfohlenen Normalpreise für die einzelnen Artikel zu den Geschäfts-zeiten in Echtzeit auf Basis der PREISAKTIONEN-Tabelle zu berechnen. Deutlich sinn-voller erscheint das Vorgehen, die Preisempfehlungen für die Eckartikel außerhalb der Geschäftszeiten zu berechnen und sie als Spaltenwert in einer Datenbanktabelle zu spei-chern, sodass sie zu den Geschäftszeiten als Wert direkt abgerufen werden können. Da jeden Sonntag neue Preisaktionen von den Wettbewerbern angekündigt werden, können die Berechnungen sonntags, außerhalb der Geschäftszeiten, durchgeführt werden.
Es wurde deswegen eine neue HANA-Datenbanktabelle EMPFOHLENE_NORMALPREISE erstellt, die über die zwei Spalten ARTIKEL (VARCHAR) und EMPFOHLENER_NORMAL-PREIS (DECIMAL(6,2)) verfügt. In dieser Tabelle sollen ausschließlich die einzelnen Eck-artikel und die für sie empfohlenen Normalpreise gespeichert werden. Diese Datenbank-tabelle und ihre Werte können von anderen Softwaresystemen genutzt werden, die die Preissetzung von digitalen Preisschildern steuern oder die als Koordinationssystem für die physischen Preisschilder fungieren. Als Schnittstelle, um die konkreten Preisemp-fehlungen zu anderen Softwaresystemen zu kommunizieren, kann folglich die HANA-Cloud-Datenbank genutzt werden. In den anderen Softwaresystemen muss nur ein ent-sprechendes SELECT-Statement zur HANA-Datenbank implementiert werden.
Um die Datenbanktabelle in der Webapplikation zu verwalten, wurden Middlewares im-plementiert, die das Anlegen und das Löschen der Datenbanktabelle, das Löschen aller Zeilen, das Einfügen von Datensätzen und das Auslesen aller Datensätze umsetzen. Die Middlewares werden hier nicht erläutert, da ihre Codestruktur mit den Middlewares für die Datenbanktabelle PREISAKTIONEN übereinstimmt. Um die Datenbanktabelle neu anzulegen und zu löschen, wurde die View des Reiters „Andere Datenbankfunktionen“ um zwei entsprechende Knöpfe erweitert, und diese Knöpfe mit den entsprechenden Middlewares verknüpft. Die Middleware zum Auslesen aller Datensätze wird im neuen Standardlayout-Reiter „Zeige empfohlene Normalpreise“ verwendet, der wie der Reiter „Zeige Daten“ für die Datenbanktabelle PREISAKTIONEN funktioniert. Wie die Middle-wares zum Löschen aller Zeilen und zum Einfügen von Zeilen verwendet werden, wird in Kapitel 4.5.3 erläutert.
Transformation der zu vergleichenden Datensätze
Nach der automatisierten Beschaffung der aktuellen Wettbewerbsdaten durch die Web-Scraper können die beschafften Daten in der Webapplikation übersichtlich angesehen werden („Zeige Daten“-Reiter). Ein exemplarischer Ausschnitt der Daten wird in der folgenden Abbildung dargestellt. Aus der Untersuchung von Müller geht hervor, dass es sich bei dem Normalsortiment der Warengruppen „Obst und Gemüse“ und „Frische-Theken“ sowie bei den Markenartikeln des Normalsortiments der Warengruppen „Grund-nahrungsmittel“, „Molkereiprodukte“ und „Alkoholfreie Getränke“ um Eckartikel handelt.
Auf Basis der übersichtlichen Darstellung der Datensätze können die einzelnen Eckarti-kel identifiziert werden. In dem gezeigten Ausschnitt fällt der Artikel „Philadelphia“ als Molkereiprodukt unter die Kategorie der Eckartikel. Zudem fallen die Artikel „Äpfel“, „Orangen“, „Speisekartoffeln“ und „Kulturchampignons“ als Obst und Gemüse unter die Kategorie der Eckartikel. Der Artikel Rotkäppchen-Sekt gehört zu den Warengruppen der „Alkoholischen Getränke“ und ist kein Eckartikel. Für den Artikel „Speisekartoffeln“ wurde bei der Preisaktion der Sonderangebotspreis angegeben, aber es wurde kein Nor-malpreis und keine Preisreduktion angegeben. Dieser Datensatz kann deshalb nicht ver-wendet werden, da die Normalpreise der Wettbewerber unterboten werden sollen, und der Sonderangebotspreis als Information nicht ausreicht.
Im Rahmen dieser Arbeit wurden nur die Preisdaten eines Wettbewerbers beschafft, allerdings soll hier bereits diskutiert werden, wie vorgegangen werden muss, wenn die Preisdaten mehrerer Wettbewerber beschafft wurden. Um den Wettbewerbspreis für ei-nen Eckartikel zu unterbieten oder zu halten, muss der niedrigste Normalpreis für diesen Eckartikel über alle Wettbewerber identifiziert werden. Ein Eckartikel ist beispielsweise der erwähnte Philadelphia-Käse mit der Einheit (Packungsgröße) 175g. Um die Normal-preise aller Wettbewerber für den Philadelphia (175g) zu vergleichen, müssen in einem ersten Schritt alle Datensätze, die genau diesen Eckartikel betreffen, aus der Datenbank gelesen werden. Diese Aufgabe kann durch eine entsprechende WHERE-Klausel eines SELECT-Statements geleitet werden, die abfragt, ob die Spalte ARTIKELNAME und die Spalte EINHEIT eines Datensatzes einen bestimmten Wert aufweist.
Ein zu lösendes Problem ist, dass auf den Webseiten der verschiedenen Wettbewerber nicht immer die gleichen Strings für den Artikelnamen und die Einheit genutzt werden, obwohl sie den gleichen Artikel referenzieren. Während die Packungsgröße (EINHEIT) für den Philadelphia bei der Aldi-Nord-Webseite mit dem String „175-g-Packung“ be-zeichnet wird, könnte sie auf der Webseite eines anderen Wettbewerbers beispielsweise mit dem String „175g Packung“ bezeichnet werden. Der Datensatz der verschiedenen Wettbewerber könnte dann nicht mit der gleichen WHERE-Klausel selektiert werden. Zudem kann das Problem auftreten, dass derselbe Wettbewerber im Rahmen von zwei verschiedenen Preisaktionen abweichende Strings für den gleichen Eckartikel benutzt.
Um das Problem zu lösen, sollen alle Datensätze, die einen bestimmten Eckartikel refe-renzieren, so transformiert werden, dass sie den gleichen String für die Spalte ARTI-KELNAME und EINHEIT aufweisen. Um diese Datentransformation durchzuführen, wurde zunächst auf der Datenbankzugriffsschicht eine Middleware transformiereDatensatz de-finiert, die das SQL-Kommando ‘UPDATE PREISAKTIONEN SET ARTIKELNAME = ?, EIN-HEIT = ? WHERE ARTIKELNAME = ? AND EINHEIT = ?’ ausführt. Die ersten beiden Platzhalter geben folglich an, auf welchen Wert die Spalten ARTIKELNAME und EINHEIT eines Datensatzes gesetzt werden sollen, während die letzten beiden Platzhalter be-stimmten, für welche Datensätze die Änderung durchgeführt werden soll. Die Middle-ware erwartet als Eingabeparameter ein Array mit vier Elementen, die die Platzhalter befüllen.
Auf der Anwendungsschicht wurde eine Middleware transformiere_PREISAKTIONEN an-gelegt. Um die Middleware starten zu können, wurde ein neuer Reiter „Transformiere Daten“ in dem Main-Layout eingefügt. In der transformiere_PREISAKTIONEN-Middle-ware sollen die Datentransformationen für alle Eckartikel der PREISAKTIONEN-Tabelle durchgeführt werden. Der Code wird Abbildung 64 dargestellt. Es wurden vier beispiels-hafte Transformationen für die Artikel durchgeführt, die in Abbildung 63 als Eckartikel identifiziert wurden, wobei für die einzelnen Transformationen die bereits erläuterte Mi-ddleware transformiereDatensatz genutzt wird. Für den Philadelphia-Artikel soll die Spalte ARTIKELNAME auf „Philadelphia“ und die Spalte EINHEIT auf „175“ gesetzt wer-den. Die EINHEIT-Spalte soll für alle Eckartikel in Gramm als Integer angegeben wer-den. Das dritte und vierte Element des Arrays, das an transformiereDatensatz weiter-gegebenen wird, identifizieren die zu ändernden Datensätze (WHERE-Klausel). Da im Rahmen dieser Arbeit nur die Daten eines einzelnen Wettbewerbers beschafft wurden, existieren hier noch keine Transformationen für verschiedene Datensätze, die den glei-chen Eckartikel referenzieren.
Während Philadelphia mit der Packungsgröße von 175g einen bestimmten Markenartikel identifiziert, stellt sich bei Äpfeln, Orangen und Kulturchampignons die Frage, wie sie bezüglich des Vergleichs mit anderen Wettbewerbern als Artikel klassifiziert werden kön-nen. Den Zusatzinformationen zu den Artikeln (Abbildung 63) kann entnommen werden, dass es sich bei den drei Obst- bzw. Gemüseartikeln jeweils um (Handels)Klasse 1 han-delt. Es erscheint sinnvoll, Äpfel der Handelsklasse 1 von Aldi-Nord nur mit Äpfeln der gleichen Handelsklasse von den anderen Wettbewerbern zu vergleichen. Folglich werden die Äpfel der Handelsklasse 1 als Artikel von den Äpfeln anderer Handelsklassen abge-grenzt. Da die Identifikation der Datensätze eines bestimmten Eckartikels, wie bereits diskutiert, über die Spalten ARTIKELNAME und EINHEIT erfolgen soll, wird hier die In-formation der Handelsklasse 1 in den Artikelnamen hinzugefügt, sodass sich die Be-zeichnung „Äpfel_H1“ ergibt. Für die anderen Obst- und Gemüseartikel wurde das glei-che Vorgehen gewählt.
Im Rahmen der in dieser Arbeit gelesenen Literatur wurde keine Aussage darüber ge-funden, ob bei Obst- und Gemüseartikeln die Preise für verschiedene Gewichte wettbe-werberübergreifend proportional verglichen werden, oder ob der Preis nur verglichen wird, wenn er für das gleiche Gewicht angegeben wird. Beispielsweise werden die Oran-gen bei Aldi-Nord in einem 1,5kg-Netz verkauft und es stellt sich die Frage, ob die Kun-den diesen Preis für 1,5kg mit dem Preis für ein 1kg-Netz bei einem anderen Wettbe-werber proportional vergleichen, oder ob sie den Preis für 1,5kg nur mit anderen Preisen für 1,5kg vergleichen.
Eine differenzierte Literaturrecherche zur Beantwortung dieser Frage hätte zu einer Überschreitung des Umfangs dieser Arbeit beigetragen. Deswegen wird hier das Vorge-hen gewählt, den Preis für die konkrete Einheit (1500g) von z. B. Orangen der Handels-klasse 1 zu berechnen. Falls doch eine Vereinheitlichung des Preises von Orangen auf beispielsweise 1kg stattfinden soll, könnten die empfohlenen Preise für die verschiede-nen Packungsgrößen, die in der Datenbanktabelle EMPFOHLENE_NORMALPREISE ge-speichert werden, durch eine relativ einfache mathematische Funktion in Relation ge-setzt werden. Es müsste nur der empfohlene Normalpreis für 1500g Orangen durch 1,5 geteilt, und mit dem empfohlene Normalpreis für 1000g Orangen verglichen werden, und der niedrigere Preis gewählt werden. Die aus den Transformationen (Abbildung 64) resultierenden Datensätze werden in der folgenden Abbildung dargestellt.
In der Middleware transformiere_PREISAKTIONEN wurden vier exemplarische Transfor-mationen implementiert. Um im Rahmen einer Erweiterung dieser Arbeit sämtliche Eck-artikel über alle Wettbewerber auf die definierte Form für die Spalten ARTIKELNAME und EINHEIT zu bringen, ist ein sehr hoher Analyse- und Implementierungsaufwand zu er-warten. Allerdings resultiert aus der Definition der Transformationen ein automatisierter Prozess. Denn sobald für den Eckartikel eines Wettbewerbers eine Transformationsregel definiert ist, wird der Eckartikel, wenn er in einer späteren Preisaktion wiederholt ange-boten wird, durch die gleiche Transformationsregel bearbeitet, falls er die gleiche Be-zeichnung des Artikelnamens und der Einheit aufweist. Falls Abweichungen bei der Be-zeichnung der Spalten auftreten, müssten allerdings weitere Transformationsregeln de-finiert werden, um den Abweichungen Rechnung zu tragen.
Durch die asynchrone Architektur von Node.js kann eine hohe Anzahl von Transforma-tionen fast gleichzeitig gestartet und an die performante HANA-Datenbank delegiert werden. Da im Rahmen der Datenbanktransaktionen nur auf zwei Spalten gearbeitet werden muss, können zudem die Vorteile der spaltenbasierten Speicherung der HANA (Kapitel 4.3.1.1) ausgenutzt werden.
Berechnung der empfohlenen Normalpreise
Sobald alle Datensätze, die den gleichen Artikel referenzieren, über die gleiche Benen-nung der Spalten ARTIKELNAME und EINHEIT verfügen, können sie mit einem SELECT-Statement ausgelesen werden, dessen WHERE-Klausel genau diese Spaltennamen se-lektiert. Auf der Datenbankzugriffsschicht wurde eine Middleware select_artikel ange-legt, die das SQL-Kommando ‘SELECT WETTBEWERBER, NORMALPREIS, STARTDATUM FROM PREISAKTIONEN WHERE ARTIKELNAME = ? AND EINHEIT = ?’ ausführt. Warum neben den Normalpreis auch die Spalten WETTBEWERBER und STARTDATUM benötigt werden, wird später erläutert.
Um den empfohlenen Normalpreises für die Strategie des Unterbietens und des Haltens des Wettbewerbs zu berechnen, wurden die Middlewares berechne_empfohlenen_nor-malpreis_unterbieten und berechne_empfohlenen_normalpreis_halten auf der Anwen-dungsschicht definiert. Im Folgenden wird die Middleware der Unterbietungsstrategie erläutert. Die folgende Abbildung zeigt den Code. Die Middleware erwartet drei Einga-beparameter. Als erster Parameter wird der Name des Artikels erwartet, der zusammen mit seinem empfohlenen Normalpreis in der EMPFOHLENE_NORMALPREISE-Datenbank-tabelle (Kapitel 4.5.1) gespeichert werden soll. Als zweiter und dritter Eingabeparameter werden die für einen bestimmten Artikel vereinheitlichten Strings für die Spalten ARTI-KELNAME und EINHEIT erwartet. Diese beiden Eingabeparameter werden in ein Array inputArray gepusht, das wiederum für den Aufrufs der select_artikel-Middleware (letzter Absatz) genutzt wird, um alle Datensätze auszulesen, die einen bestimmten Artikel be-treffen. Das von der select_artikel-Middleware zurückgegebene Callback-Objekt db_callback enthält als Objekt-Eigenschaft rows die Datensätze. Falls ein Fehler bei dem Datenbankzugriff eingetreten ist, oder keine Datensätze selektiert wurden, wird eine Fehlermeldung auf der Kommandozeile ausgegeben.
Im Rahmen der Berechnung des empfohlenen Normalpreises muss zuerst der minimale Normalpreises über alle Wettbewerber (Datensätze) ermittelt werden. Um den minima-len Normalpreis zu berechnen, wurde auf der Anwendungsschicht eine Middleware be-rechne_minimalen_normalpreis angelegt. Der Code der Middleware wird in der folgen-den Abbildung dargestellt. Die Middleware erwartet als Eingabeparameter das Objekt, in dem die Datensätze als Objekt-Eigenschaft rows gespeichert wurden (db_callback). Die Middleware gibt als Callback-Objekt den minimalen Normalpreis zurück.
Es kann nicht direkt der minimale Normalpreis über alle Datensätze berechnet werden. Falls mehrere Datensätze für den gleichen Wettbewerber vorliegen (d. h. es wurden im Laufe der Zeit mehr als eine Preisaktion zu dem gleichen Eckartikel gescrapt), muss zuerst der Datensatz der älteren Preisaktion entfernt werden. Denn wenn der neuere Datensatz über einen anderen, aktuellen Normalpreis für den Eckartikel verfügt, soll der veraltete Normalpreis nicht mehr bei der Berechnung des minimalen Normalpreises be-rücksichtigt werden. Aus der Datenbanktabelle PREISAKTIONEN sollen die „veralteten“ Datensätze nicht entfernt werden, weil dadurch Informationen verloren gehen würden, die für die historische Analyse eines Wettbewerbers genutzt werden könnten. Deswegen soll die Entfernung der veralteten Datensätze nur bei dem aus dem Datenbankaufruf resultierenden Array stattfinden.
Um die älteren Datensätze eines Wettbewerbers zu entfernen, wurde eine Schleife über alle Datensätze – 1 (rows.length – 1) definiert. Der letzte Datensatz muss nicht mehr überprüft werden, da die vor ihm liegenden Elemente des Arrays jeweils mit allen hinter ihnen liegenden Elementen verglichen werden, und er somit bereits mit allen Elementen verglichen wird. Die Zählvariable i der Schleife wird genutzt, um auf die Indizes des Arrays zuzugreifen. Innerhalb dieser äußeren Schleife wurde eine innere Schleife über alle Elemente definiert, die hinter dem aktuell referenzierten Element (i) der äußeren Schleife liegen. Die innere Schleife startet somit bei i+1, wobei j als Zählvariable der inneren Schleife definiert wurde. Innerhalb der inneren Schleife wird geprüft, ob die Spalte WETTBEWERBER des aktuell von der äußeren Schleife referenzierte Datensatzes mit dem Wettbewerber der Datensätze übereinstimmt, über die mit j iteriert wird. Falls der Wettbewerber bei zwei Datensätzen übereinstimmt, wird der Datensatz mit dem älteren STARTDATUM aus dem rows-Array entfernt.
Da sich innerhalb von Schleifen über das Array befunden wird, kann ein veralteter Da-tensatz allerdings nicht sofort aus dem Array entfernt werden. Stattdessen wird der Index des zu entfernenden Array-Elements in ein Array removeArray gepusht. Nach dem Verlassen der Schleifen werden die in removeArray gespeicherten Indizes genutzt, um die entsprechenden Elemente zu entfernen. Die Entfernung wird durchgeführt, indem die Standard-JavaScript-Array-Methode splice() auf rows ausgeführt wird, die als ersten Parameter den Index des Elements erwartet, das aus dem Array entfernt werden soll. Als zweiten Parameter erwartet splice() einen Integer, der angibt, wie viele Ele-mente von dem angegebenen Index an entfernt werden sollen. Da nur genau das eine Element entfernt werden soll, muss hier 1 angegeben werden.
Nach dem Entfernen der veralteten Datensätze kann der minimale Normalpreis über alle Wettbewerber bzw. Datensätze ermittelt werden, indem eine Schleife über alle Daten-sätze definiert wird, und bei jeder Iteration geprüft wird, ob der Normalpreis geringer ist als das bisherige Minimum. Das Minimum (Dezimalzahl) wird anschließend als Call-back-Objekt der Middleware gesetzt.
Nach dem Aufruf der berechne_minimalen_normalpreis-Middleware und dem Erhalt des minimalen Normalpreises über alle Datensätze, soll im Rahmen der berechne_empfoh-lenen_normalpreis_unterbieten-Middleware (Abbildung 66) als nächster Schritt ein kon-kreter Unterbietungspreis ermittelt werden. Es wurde eine weitere Middleware be-rechne_unterbietungspreis auf der Anwendungsschicht definiert, die als Eingabepara-meter den berechneten minimalen Normalpreis erwartet und als Callback-Objekt den empfohlenen Normalpreis zurückgibt. Der Code der Middleware wird in der folgenden Abbildung dargestellt.
In den Handlungsempfehlungen von Müller wird zwar herausgearbeitet, für welche Eck-artikel eine Unterbietungsstrategie erfolgen soll, aber es wird nicht herausgearbeitet, wie eine Unterbietung monetär umgesetzt werden soll. Es kann hier allerdings auf die verhaltenstheoretische Hypothese verwiesen werden (Kapitel 2.1.2.1), dass bestimmte Preisschwellen existieren, bei denen sich die Preisbewertung sprunghaft verändert, da der Preis einer anderen Kategorie zugeordnet wird (Diller 2008, S. 128). Diller merkt allerdings an, dass die Preisschwelle der individuellen Kunden nicht genau bestimmt werden kann, und dieses Wissen somit begrenzt nutzbar ist (2008, S. 129).
Eine weitere ausführliche Literaturrecherche, die die genannte Fragestellung untersucht, hätte zu einer Überschreitung des Umfangs dieser Arbeit geführt. Allerdings könnte im Rahmen einer Erweiterung dieser Arbeit untersucht werden, bei welchem Wert die nächst niedrigere Preisschwelle für einen bestimmten Normalpreis X liegt. Durch ein if-Abfrage könnte dann der Unterbietungspreis (nächst niedrigere Preisschwelle) für einen bestimmten minimalen Normalpreis berechnet werden. Da hier keine konkrete Regel vorliegt und implementiert werden kann, wurde als Platzhalter-Algorithmus implemen-tiert, dass der Unterbietungspreis 5 Cent unter dem minimalen Normalpreis liegt, der der Middleware übergeben wurde.
Es ist anzumerken, dass in JavaScript bei der Arbeit mit Floats und Dezimalzahlen Prob-leme auftreten (W3Schools o o. J.). So ergibt beispielsweise die Addition von 0.2 und 0.1 den Wert 0.30000000000000004 (W3Schools o o. J.). Um diese Fehler zu vermei-den, können im Rahmen einer Berechnung die Dezimalzahlen durch eine Multiplikation auf Integer-Zahlen (ganze Zahlen) gebracht werden, was zu exakten Ergebnissen führt (W3Schools o o. J.). In dem Platzhalter-Algorithmus wurde diese Vorgehensweise an-gewendet.
Nach dem Aufrufen der berechne_unterbietungspreis-Middleware kann in der be-rechne_empfohlenen_normalpreis_unterbieten-Middleware (Abbildung 66) der zurück-gegebene Unterbietungspreis anschließend, zusammen mit entsprechenden Eckartikel-namen, in die Datenbanktabelle EMPFOHLENE_NORMALPREISE (Kapitel 4.5.1) gespei-chert werden. Die Middleware insert_empfohlenen_normalpreis führt den Insert für die EMPFOHLENE_NORMALPREISE-Datenbanktabelle durch. Falls Probleme beim Insert auf-treten, wird eine entsprechende Fehlermeldung auf der Kommandozeile ausgegeben. Wurde der Datensatz erfolgreich in der Datenbanktabelle gespeichert, wird eine Erfolgs-meldung auf der Kommandozeile angezeigt.
Die bereits erwähnt Middleware erechne_empfohlenen_normalpreis_halten berechnet die empfohlenen Normalpreise für die Strategie des Haltens des Wettbewerbs. Der Code der Middleware stimmt genau dem Code der Middleware berechne_empfohlenen_nor-malpreis_unterbieten überein, bis auf den Unterschied, dass die berechne_unterbie-tungspreis-Middleware nicht aufgerufen wird, weil der minimale Normalpreis bereits dem empfohlenen Normalpreis entspricht. Die Middleware berechne_empfohlenen_nor-malpreis_halten wird aufgrund ihrer hohen Übereinstimmung mit der berechne_emp-fohlenen_normalpreis_unterbieten-Middleware hier nicht explizit erläutert.
Zuweisung der einzelnen Eckartikel zu einer Strategie (Präsentationsschicht)
In dem Main-Layout wurde ein Reiter angelegt, der den Prozess der Berechnung der empfohlenen Normalpreise für alle Eckartikel startet. Die folgende Abbildung zeigt den Code der entsprechenden Routing-Middleware. Zuerst werden alle Datensätze der EM PFOHLENE_NORMALPREISE-Tabelle gelöscht, da nur die aktuellsten empfohlenen Nor-malpreise in der Datenbanktabelle stehen sollen. Falls ein Fehler beim Löschen auftritt, wird der Prozess abgebrochen und die Errors in der View errors.hbs angezeigt.
Falls das Löschen erfolgreich war, wird mit der Berechnung der empfohlenen Normal-preise für die einzelnen Eckartikel fortgefahren. Falls für einen Eckartikel nach Müller eine Unterbietungsstrategie erfolgen soll, kann die Middleware berechne_empfohle-nen_normalpreis_unterbieten für den Eckartikel aufgerufen werden. Falls für einen Eck-artikel nach Müller die Strategie des Haltens des minimalen Wettbewerbspreises erfol-gen soll, kann die Middleware berechne_empfohlenen_normalpreis_halten aufgerufen werden. Es kann hier folglich zentral definiert werden, für welche Eckartikel welche Stra-tegie gelten soll.
Wie bereits erwähnt, erwarten die beiden Middlewares als ersten Parameter den Arti-kelnamen, mit dem ein Eckartikel in der EMPFOHLENE_NORMALPREISE-Tabelle identi-fiziert werden soll, während als zweiter und dritter Parameter die Strings erwartet wer-den, mit denen die Datensätze des Eckartikels in der PREISAKTIONEN-Tabelle (Spalte ARTIKELNAME und EINHEIT) identifiziert werden können. Der Artikelname in der Tabelle EMPFOHLENE_NORMALPREISE soll die Spaltenwerte für ARTIKELNAME und EINHEIT der PREISAKTIONEN-Tabelle zu einem einzelnen Bezeichner aggregieren, beispielsweise „Äpfel_H1_175“ als Aggregation der Spaltenwerte „Äpfel_H1“ und „2000“. Durch die Aggregation können die Eckartikel der EMPFOHLENE_NORMALPREISE-Tabelle durch nur eine Spalte identifiziert werden und dadurch performanter abgerufen werden. Die aus dem Berechnungsprozess resultierenden Datensätze können im Reiter „Zeige empfoh-lene Normalpreise“ eingesehen werden. Die folgende Abbildung zeigt die View für die diskutierten Eckartikel.
Recent Comments