Bestand, Nachschub und Dokumente je Artikel auf einer Seite

Ausgangslage

Der Projektordner sagt nicht, was hier gelöst wurde oder was Menschen vorher taten. Kein README, keine Anforderungsbeschreibung, keine Ticketverweise; die Commit-Nachrichten lauten fast durchgehend „update“ oder „add new features“. Daraus eine Geschichte zu rekonstruieren wäre Erfindung.

Indirekter Hinweis, mehr nicht: Die Quelldaten liegen in rund 25 getrennten Warehouse-Sichten plus einem separaten Produktdatensystem, und im Ordner liegt eine förmliche Anfrage an das Datenteam nach weiteren Feldern. Der Umfang ist also plausibel Feld für Feld gewachsen, weil Nutzer nach Dingen fragten.

Ansatz

Ein täglicher Lauf startet eine Stunde nach der Aktualisierung der darunterliegenden Warehouse-Schicht. Eine einzige große SQL-Abfrage — rund dreißig verkettete Unterabfragen — setzt je Artikel zusammen: Bestand je Lagerort, Bestellungen und Wiederbeschaffungszeiten, Prognose, Produktion und Chargenverfall, Absatz und Kundenkonzentration, Verbrauch und Verpackung.

Das Ergebnis wird flachgelegt auf ein Dokument je Artikel und Land, damit Bestellungen und Absätze am empfangenden Markt hängen statt global vermischt zu werden. Jedes Dokument wird eingebettet und in einen Suchindex geschrieben; Dokumente, die in einem Lauf nicht neu geschrieben wurden, werden danach gelöscht — ein Artikel, dessen Bestand auf null fiel, verschwindet, statt liegenzubleiben.

Ein zweiter Index hält Produktinhalte aus dem Produktdatensystem, verbunden über die Artikelnummer. Alles, was der Nutzer sieht — Filter, Warnregeln, Kennzahlen zum gebundenen Kapital, ABC/XYZ-Einteilung, CSV-Export — läuft im Browser.

Der Punkt, an dem es anders hätte laufen können

Der Bestand wird aus dem Bewegungsprotokoll hergeleitet statt aus der fertigen Bestandsansicht.

Der naheliegende Weg war die Bestandssicht des Warehouse: eine Zeile je Artikel und Lagerort, bereits aggregiert. Sie wurde zuerst verwendet und dann bewusst verworfen — denn diese Sicht schreibt keine Zeilen mehr, sobald ein Bestand null erreicht. Der letzte Wert ungleich null taucht damit auf ewig als „aktuell“ auf. Der Kommentar im Code hält einen beobachteten Fall fest: ein 91 Tage alter Bestand, gemeldet als Live-Bestand.

Der Ersatz liest das Bewegungsprotokoll und nimmt je Artikel, Lagerort und Kategorie die jüngste Zeile. Teurer — aber er fängt genau die Bewegung, die einen Bestand auf null bringt.

Dieselbe Haltung wiederholt sich an anderer Stelle: Die Verknüpfung von Artikeln zu Katalogprodukten hat bewusst keinen Rückfall auf Beschreibungsähnlichkeit. Der hätte die Trefferquote erhöht — und plausible Fehlzuordnungen über Produktfamilien hinweg erzeugt.

Ergebnis

Rund 334.000 Dokumente im Index, aufgebaut aus etwa 25 Warehouse-Sichten. Etwa drei Monate Arbeit, 60 Commits über 21 Arbeitstage, eine Person — mit Schüben von vier bis neun Commits und wochenlangen Pausen dazwischen, also erkennbar neben anderen Aufgaben.

14 Warnregeln melden Artikel, die Aufmerksamkeit brauchen: knapper Bestand, Überbestand, Ladenhüter, nahender Verfall, überfällige Lieferantenbestellung.

Bewusst begrenzt: Nur lesend. Nichts wird nach SAP oder ins Produktdatensystem zurückgeschrieben; Anforderungen, Umlagerungen und Ausbuchungen passieren weiterhin von Hand in den Quellsystemen. Einmal täglich, keine Historie — keine Echtzeit-Verfügbarkeitsprüfung, und weil der Index bei jedem Lauf überschrieben wird, kann das System nicht sagen, was sich seit gestern geändert hat.

Offen benannt: Die Warnregeln laufen im Browser, wenn jemand sucht — es wird niemand benachrichtigt. Die Suche liefert höchstens 500 Zeilen, der Export 10.000, und die Filterung läuft über diesen Ausschnitt; der Code markiert das selbst als etwas, das serverseitig gehören würde. Und es gibt keine Tests: Jede Änderung wird von Hand geprüft.