In diesem Blogpost werden gleich eine ganze Reihe an spannenden Herausforderungen diskutiert, die sich so vermutlich in unzähligen anderen Firmen wiederfinden.

Konkret geht es einfach nur um eine Auslastungsanzeige im Lager. Der Kunde möchte auf einem Board anzeigen wie viel in einzelnen Lagerbereichen heute (noch) zu tun ist und wie viel davon schon erledigt ist. Damit können sich die Lagermitarbeiter rechtzeitig und selbstständig einen Überblick verschaffen, ob das Personal sinnvoll über die Lagerbereiche verteilt ist, bevor kurz vor Feierabend jemand merkt, dass ein Defizit in einem bestimmten Bereich die komplette Mannschaft daran hindert, pünktlich Feierabend zu machen.

Da wäre zunächst einmal das große „SAP-Veränderungsproblem“. Dabei geht es konkret darum, dass Verändungen in SAP per se teuer, langwierig und für alle Beteiligten eine Geduldsprobe sind. Die initiale Idee, einfach einen kleinen Funktionsbaustein zu schreiben, der nach einer gewissen Logik die offenen Transportauftragspositionen über ein intelligentes SELECT kumuliert und als hochkomprimierte Tabelle zum Aufrufer – der Peakboard-Box – zurückliefert, ist also unerwünscht. Die zweitbeste Methode – und dafür haben wir uns entschieden – ist eine Query. Sie besteht im Wesentlichen aus einem Join von LTAK und LTAP. Das sind die beiden Tabellen für Lieferköpfe und Lieferpositionen. Anhand einiger Attribute werden die heute fälligen TAs herausgefiltert (z.B. Anlagedatum und Uhrzeit). Je nach Tageszeit liefert die Query bis zu 20.000 Zeilen. Das stellt kein größeres Problem dar und kann von Peakboard problemlos verarbeitet werden. Die Selektionskriterien werden als Variante abgelegt. Auf der Seite von Peakboard lässt sich die Query samt Variante dann ganz einfach als SAP-Datenquelle direkt einbinden.

Der Screenshot zeigt den XQL-Aufruf, der die Query ausführt.

Nun kommt die spannende Weiterverarbeitung. Wir haben es ja in der Ergebnismenge mit einzelnen TA-Positionen zu tun, wollen aber später nur die Anzahl pro Lagerbereich ausgeben. Diese Kumulierung findet in einem Lua-Script statt. Ziel-Variable sind einige statische Variablen für jeden Lagerbereich. Der Screenshot zeigt drei für den Lagerberich PLK (einen für die Anzahl der Position, einen für die offenen Picks, einen für die erledigen Picks).

Das Lua-Script, das im Refreshed-Event der Datenquelle hinterlegt ist, wird jedes Mal aufgerufen, wenn sich Daten geändert haben. Es werden zunächst drei lokale Variablen deklariert und danach per Schleife die komplette Ergebnismenge durchlaufen. Wenn die aktuelle Zeile der Schleife zu einem Lagerbereich gehört (das Feld heißt Queue, bedeutet aber Lagerbereich) wird TAPOS um eins erhöht. Je nachdem, ob die Position bereits quittiert ist, werden die Picks jeweils zu den Erledigten oder den Offenen hinzugezählt. Zu guter Letzt werden die lokalen Variablen in die globalen Datenelemente übertragen. Wir gehen den Umweg über die lokalen Variablen beim Durchzählen, um ein Flackern aller verbundenen Steuerelemente zu verhindern.

local PLKTAPOS = 0
local PLKPicksErledigt = 0
local PLKPicksOffen = 0

for index, item in pairs(Data.saplieferungen) do
    if item["LTAK-QUEUE"] == 'WA PLK' then
       PLKTAPOS = PLKTAPOS + 1
       if item["LTAP-PQUIT"] == 'X' then PLKPicksErledigt = PLKPicksErledigt + tonumber(item["Z_PICKS"]) else PLKPicksOffen = PLKPicksOffen + tonumber(item["Z_PICKS"]) end
    end
end

Data.PLKTAPOS = PLKTAPOS
Data.PLKPicksErledigt = PLKPicksErledigt
Data.PLKPicksOffen = PLKPicksOffen

Die folgenden Screenshots zeigen die tatsächliche Visualisierung. Sie besteht neben strukturellen Elementen aus drei Textblöcken und einem Linear Gauge. Alle Steuerelemente sind per Datenbindung an die Datenobjekte gebunden. Der nächste Screenshot zeigt die Anzeige im Preview.

Dieses Beispiel ist hervorragend geeinigt, um vermeintlichen Schwächen von SAP entspannt zu begegnen. Man bedient sich der Bordmittel, die eben zur Verfügung stehen (Query) und nutzt dann ein einfaches Script, um die Daten zu kumulieren.

Teilen:
FacebookTwitter