Artikellisten für Kunden — ohne zweiten, kundensicheren Index

Ausgangslage

Der Auslöser ist im Projektordner nicht dokumentiert. Keine README im Wurzelverzeichnis, keine Anforderungsbeschreibung, und neun von zehn Commit-Nachrichten lauten „update“, „add new features“ oder „fix bug“.

Belegt ist zweierlei. Im Ordner liegt eine kundenspezifische Artikelliste als CSV — 1.366 Zeilen, rund 70 Spalten: Artikelnummer, EANs je Verpackungseinheit, Mindestbestellmengen, Gewichte, Maße, Ursprungsland, Gefahrgut- und CLP-Einstufung, Marketingtexte, Datenblatt-Dateinamen. Und Code-Kommentare bezeichnen später ergänzte Felder ausdrücklich als „Datenblatt-Lückenfelder“ — also als Felder, die in genau einer solchen Liste gefehlt hatten.

Dass solche Listen zuvor manuell aus ERP- und PIM-Daten in Excel zusammengetragen wurden, ist naheliegend, aber nicht belegt. Belegt ist nur, dass die Feldauswahl der Anwendung nachträglich an dieser Liste ausgerichtet wurde.

Ansatz

Eine Flask-Anwendung, die drei Datenquellen zusammenführt.

Der Katalog kommt aus zwei Suchindizes: ERP-Stammdaten (ein Dokument je Artikel und Land, in der Anwendung zu einer Zeile je Artikel zusammengefasst) und Produktinhalte mit mehrsprachigen Texten und Dokumentlinks, verbunden über die Artikelnummer. Filter laufen als Facetten über denselben Index und kaskadieren dadurch. Die Artikellisten liegen in einer eigenen relationalen Datenbank. Die Kaufhistorie wird bei Bedarf gegen das Data Warehouse abgefragt: gelieferte Auftragspositionen, je Artikel aggregiert.

Zusammengehalten wird alles von der Kundenzuordnung. Sie steckt in einer einzigen Funktion, und jede Listen- oder Historienabfrage bekommt die Kundennummer von dort — nie aus dem Request. Zwei Modi sind vorgesehen: intern (Mitarbeitende wählen einen Kunden) und extern (Identität aus dem Anmeldetoken). Der Wechsel ist eine Änderung an dieser einen Funktion, nicht an den 19 Routen.

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

Der kundenseitige Katalog liest denselben Index, der intern auch Bestände, Lagerwerte, Bestellungen, Lieferanten und Topkunden enthält.

Ein separater, kundensicherer Index wurde bewusst nicht gebaut. Stattdessen wird die Trennung serverseitig erzwungen: eine explizite Positivliste erlaubter Felder, und die Suchmaschine gibt nur ausgewählte Felder zurück. Was dort nicht steht, erreicht den Client nicht.

Das spart einen zweiten Index samt Beladung — verlagert die Verantwortung aber in eine Liste, die bei jedem neuen Feld gepflegt werden muss. Der Code sagt das selbst und markiert eine Ausnahme als „für die interne Phase in Ordnung, vor externer Freigabe prüfen“.

Wie ernst das Prinzip genommen wird, zeigt der letzte Commit: Zurückgezogene Dokumente gingen im internen Modus bis dahin mit, damit Mitarbeitende sie über einen Umschalter prüfen konnten. Der Commit entfernt den Umschalter samt Oberflächen-Code und filtert immer serverseitig — die Prüfansicht wurde zugunsten eines Codepfads aufgegeben, in dem die URL eines zurückgezogenen Sicherheitsdatenblatts das Backend nicht verlassen kann.

Ergebnis

Rund 3.250 Zeilen Python in elf Modulen plus etwa 1.900 Zeilen Oberfläche, 19 Routen, drei angebundene Systeme über drei Suchindizes und zwei Datenbanken, drei Export-Layouts mit 74, 75 und 81 Spalten, zehn Sprachen. Knapp acht Wochen Kalenderzeit, eine Person.

Bewusst nicht enthalten: keine Bestellung, keine Preise, keine Bestände. Listen sind Listen — kein Abschluss, kein Rückschreibeweg ins ERP. Weitergearbeitet wird außerhalb des Systems.

Ehrlich zum Stand: Der externe Kundenlogin ist noch nicht scharf. Standard ist der interne Modus, die Zuordnung für Phase 2 im Code als offen vermerkt; bis dahin wählen Mitarbeitende den Kunden manuell. „Gekauft“ ist außerdem ein Näherungswert — gelieferte Auftragspositionen statt Rechnungen, im Code als bestmögliches verfügbares Signal benannt.