Änderungsprotokoll

Chronologische Liste der umgesetzten Arbeitspakete und Änderungen. Der jeweils zugehörige Git-Commit steht in Klammern (Kurz-Hash sichtbar in der Fußzeile der Anwendung).

Jede Bestellung erhält beim Anlegen automatisch eine lückenlose, fortlaufende Nummer (1, 2, 3 …).

• Umsetzung über eine eigene Zählertabelle (Modell Nummernkreis) mit Zeilensperre (SELECT … FOR UPDATE).
• Auch bei gleichzeitigem Anlegen durch mehrere Nutzer eindeutig; bei Abbruch wird keine Nummer „verbraucht„ (kein Loch).
• Feld bleibt ein Textfeld, damit importierte Altdaten ihre alte Nummer behalten. Im Admin ist die Nummer schreibgeschützt.
• Abgesichert durch Tests (u. a. ein Parallel-Test mit 8 gleichzeitigen Anlegern).

Benutzeroberfläche außerhalb des Django-Admin:

• Liste unter /bestellungen/ mit Suche und Filtern (Schule, Lieferant, „Rechnung abgelegt“), 25 Einträge pro Seite.
• Detailansicht unter /bestellungen/<Nr>/ mit allen Feldern in sechs Gruppen.
• Zugriff nur mit Leserecht: ohne Anmeldung → Login, ohne Rolle → „verboten„ (403).

Siehe eigene Seite Gestaltung. Kurz:

• Erst am Vorbild der Website landkreis-esslingen.de, dann auf Wunsch an die Schülerdatenbank (sdb.sfkr-es.de) angeglichen (Hausfarbe Gelb #FFED00, Schrift Univers, eckige Kanten, weiße Karten auf grauem Grund).
• Dunkelmodus (Mond/Sonne-Knopf in der Kopfzeile), Wahl im Browser gespeichert.

• Dieses Wiki wurde als eigener Docker-Dienst wiki auf dem Server eingerichtet (Image dokuwiki/dokuwiki:stable).
• Erreichbar als Pfad /dokuwiki auf der Domain sowie intern unter http://192.168.20.50:8001/dokuwiki/.
• Daten liegen im Docker-Volume dokuwiki_data (bleiben über Neustarts erhalten).

• Alle Seiten (auch die Login-Seite) zeigen unten einen Link zum Wiki und die laufende Programmversion (Git-Kurz-Hash + Datum).
• Der Wiki-Link passt sich dem Zugriffsweg an: intern die LAN-Adresse, über die Domain der Pfad /dokuwiki/.

• Ein schlanker nginx-Dienst (proxy) hört auf 192.168.20.50:8000 und teilt die Pfade auf: /dokuwiki → Wiki, alles andere → Django.
• Dadurch ist das Wiki unter dms.schulen-lraes.de/dokuwiki erreichbar, ohne den externen Proxy zu ändern (dieser reicht die ganze Domain an \:8000 weiter).
• Django wird nicht mehr direkt veröffentlicht, sondern läuft hinter dem Proxy. Das HTTPS terminiert weiterhin der externe nginx.

Dokumente (Rechnung, Angebot, Lieferschein, Sonstiges) können als PDF an eine Bestellung hochgeladen werden.

• Es werden nur PDF-Dateien angenommen (geprüft werden Dateiendung und der %PDF-Kopf); die Dateigröße ist begrenzt (Standard 20 MB).
• Beim Upload wird automatisch eine SHA-256-Prüfsumme berechnet und gespeichert – die Grundlage für die revisionssichere Ablage (AP 4.2).
• Dokumente sind an der Bestellung sichtbar: im Admin als Liste direkt am Vorgang (dort auch hochladbar) und in der Detailansicht (mit Typ, Bezeichnung, Prüfsumme und Datei-Link).
• Hochgeladene Dateien werden nur an angemeldete Nutzer ausgeliefert (Rechnungen sind vertraulich) und liegen im Docker-Volume media_data.

• Die Anwendung hat jetzt eine Versionsnummer nach „Semantic Versioning“ (MAJOR.MINOR.PATCH), sichtbar in der Fußzeile (zusätzlich der Git-Kurz-Hash als „Build„).
• Konvention: 0.<Phase>.<AP> – die Nummer entspricht dem zuletzt abgeschlossenen Arbeitspaket (z. B. 0.4.1 = Phase 4, AP 4.1).
• Bei jeder Versionsänderung wird hier im Änderungsprotokoll ein Eintrag ergänzt.

Dokumente werden jetzt revisionssicher in einem Objektspeicher (MinIO) abgelegt.

• MinIO läuft als eigener Docker-Dienst; ein Einrichtungs-Container legt den Ablage-„Eimer“ (Bucket) mit Object-Lock an – das lässt sich nur bei der Erstellung aktivieren.
• Sperre gegen Überschreiben/Löschen (WORM): Jedes hochgeladene Dokument wird automatisch für eine Aufbewahrungsfrist gesperrt (Standard 30 Tage, einstellbar). Ein gesperrtes Dokument kann nicht verändert oder gelöscht werden.
• Bewusst zunächst der Governance-Modus (nur mit Sonderrecht umgehbar) – nicht der unwiderrufliche Compliance-Modus. Die Umstellung auf Compliance und die endgültige Aufbewahrungsdauer werden später ausdrücklich entschieden.
• Dokumente werden weiterhin nur an angemeldete Berechtigte ausgeliefert; der Speicher selbst ist nicht öffentlich erreichbar.

Ein Rechnungsvorgang durchläuft feste, kontrollierte Stationen.

• Ablauf: Erfasst → Zugewiesen → In Prüfung → Freigegeben oder Abgelehnt. „Freigegeben„ und „Abgelehnt“ sind Endzustände.
• Nur erlaubte Übergänge: Sprünge (z. B. direkt von „Erfasst„ auf „Freigegeben“) oder Rückschritte werden abgelehnt – auch bei der Bearbeitung im Verwaltungsbereich (Admin).
• Bewusst als schlankes, gut wartbares Eigenmodell umgesetzt (keine schwergewichtige Zusatz-Software), da die Statusregeln zur Fachlichkeit gehören.
• Die eigentliche Zuweisung an eine prüfende Person und die Benachrichtigungen folgen in den nächsten Schritten (5.2 und 5.3).

Ein Rechnungsvorgang kann einer prüfenden/freigebenden Person zugewiesen werden.

• Zuweisung: Beim Zuweisen an eine Person wandert der Vorgang automatisch von „Erfasst„ auf „Zugewiesen“.
• Informierte Beteiligte: Zusätzlich können beliebig viele Personen als „informiert„ geführt werden (nur zur Kenntnis, ohne Zuständigkeit).
• Neue Ansicht „Meine Freigaben“: Über den Menüpunkt sieht jede angemeldete Person genau die Vorgänge, für die sie zuständig oder informiert ist – mit Kennzeichnung der Rolle.
• Gepflegt wird die Zuweisung im Verwaltungsbereich (Admin); die automatischen E-Mail-Benachrichtigungen folgen im nächsten Schritt (5.3).

Bei wichtigen Schritten im Rechnungs-Workflow verschickt die Anwendung nun automatisch E-Mails.

• Bei Zuweisung: Die zuständige Person erhält eine E-Mail, dass ihr ein Vorgang zur Prüfung/Freigabe zugewiesen wurde – mit Link auf „Meine Freigaben“.
• Bei Freigabe oder Ablehnung: Bearbeiter/in der Bestellung und alle „informierten“ Beteiligten werden über das Ergebnis benachrichtigt.
• Abschaltbar: Der Versand lässt sich per Einstellung komplett ausschalten (ohne Programmänderung).
• Versand im Betrieb über das Postfach dms@schulen-lraes.de (Microsoft 365). Ein Versandfehler bricht die Bearbeitung eines Vorgangs nie ab.
• Der Empfang von E-Mails über dieses Postfach ist vorbereitet (Zugang hinterlegt), aber noch nicht umgesetzt – das ist ein eigener nächster Schritt.

Die Anwendung kennzeichnet meldepflichtige Bestellungen automatisch und unterstützt die Quartalsmeldung an das Rechnungsprüfungsamt.

• Automatische Kennzeichnung: Liegt der Netto-Betrag über 25.000 €, wird die Bestellung beim Speichern automatisch als „Bekanntmachung/Statistik“ markiert (Melde-/Veröffentlichungspflicht). Genau 25.000 € zählt noch nicht.
• In der Beschaffungsliste erscheint dann ein gelber Hinweis „Meldung“ neben dem Netto-Betrag.
• 3-Monats-Liste an das Rechnungsprüfungsamt: Neuer Menüpunkt „3-Monats-Liste“ zeigt die dafür gekennzeichneten Bestellungen in einem wählbaren Zeitraum (Standard: die letzten drei Monate; für ein Quartal einfach Von/Bis eintragen), inklusive Summe der Netto-Beträge.
• Die Kennzeichnung „Meldung an das Rechnungsprüfungsamt“ wird weiterhin von Hand gesetzt; automatisch ist nur die 25.000-€-Bekanntmachung.

Alle Änderungen an den Fachdaten werden nun lückenlos protokolliert.

• Was wird protokolliert: Anlegen, Ändern und Löschen von Bestellungen, Dokumenten, Rechnungsvorgängen, Schulen, Lieferanten und Ansprechpartnern – jeweils mit wer, wann und welche Felder (vorher → nachher).
• Einsehbar im Verwaltungsbereich (Menü „Auditlog“) sowie direkt auf der Detailseite einer Bestellung im Abschnitt „Änderungsprotokoll“.
• Das Protokoll ist nur lesbar (nichts kann nachträglich verändert oder gelöscht werden); einsehen dürfen es die Rollen Rechnungsprüfer und Admin.
• Technisch über das etablierte Paket django-auditlog gelöst (kein Eigenbau bei einem sicherheitskritischen Thema).

Kleiner Feinschliff an der Oberfläche; das Erscheinungsbild bleibt an der echten Schülerdatenbank ausgerichtet.

• Design-Entscheidung bestätigt: hell als Standard, eckige Kanten (2 px), Hausgelb #FFED00, eigenes lokales Stylesheet (kein Tailwind). Ein alternativer Entwurf (Dunkelmodus als Standard, runde Ecken, Tailwind) wurde bewusst verworfen, weil er dem tatsächlichen Vorbild widerspricht.
• Meldungen sichtbar: Rückmeldungen der Anwendung erscheinen jetzt als kleine Einblendung („Toast“) oben rechts – grün bei Erfolg, rot bei Fehler; sie schließt sich nach wenigen Sekunden von selbst (Fehler bleiben stehen).
• Zusätzlich dezente Bildlaufleisten und gut lesbare Platzhaltertexte.
• Offen: Das echte Logo „Landkreis Esslingen“ (stets auf weißem Grund) ist noch nicht hinterlegt.

Die Oberfläche wurde auf ausdrücklichen Wunsch vollständig neu gestaltet und exakt an das Design-System der Schülerverwaltung angeglichen. Dies ersetzt die frühere Gestaltung (eigenes CSS, eckig, hell als Standard).

• Neues Erscheinungsbild: Dunkelmodus ist jetzt Standard (umschaltbar über ☀️/🌙, die Wahl wird im Browser gemerkt), abgerundete Karten mit Schatten, gelber Markenbalken unter der Kopfzeile, Reiter-Navigation als „Pillen“, kurze Einblendungen („Toasts“) für Rückmeldungen.
• Hausfarbe bleibt Gelb #FFED00 als einziger Akzent; auf Gelb immer schwarze Schrift. Schrift Univers/Arial, keine Versalien. Das Logo steht stets auf weißem Grund.
• Technik: Tailwind CSS, lokal ausgeliefert (kein Internet der Arbeitsplätze nötig). Es wurde ausschließlich die Gestaltung geändert – keine Funktion, keine Daten. Alle Tests laufen weiter.
• Offen: Die offizielle Logodatei „Landkreis Esslingen“ ist noch nicht hinterlegt (ersatzweise steht die Wortmarke in einer weißen Box).

Alle Daten lassen sich jetzt direkt in der Anwendung anlegen, bearbeiten und deaktivieren – der Verwaltungsbereich (Django-Admin) wird im Alltag nicht mehr benötigt.

• Bestellungen (A): neu anlegen (die Nummer wird automatisch vergeben und ist schreibgeschützt), bearbeiten, deaktivieren. Neuer Knopf „+ Neue Bestellung“ und Aktionen je Zeile.
• Schulen & Ansprechpartner (B): eigene Verwaltung; ein Ansprechpartner kann mehreren Schulen zugeordnet werden.
• Lieferanten (C): eigene Verwaltung. Deaktivierte Lieferanten erscheinen nicht mehr in neuen Bestellungen, bleiben aber in bestehenden erhalten.
• Auswahllisten (D): kontrollierte Werte (Art, Vergabeart, Förderprogramm) pflegen. Bereits verwendete Werte können nur deaktiviert, nicht gelöscht werden.
• Dokumente (E): PDF direkt an einer Bestellung hochladen (Prüfsumme automatisch). „Entfernen“ markiert das Dokument revisionssicher – Datei und Prüfsumme bleiben erhalten.
• Nichts wird hart gelöscht: Statt Löschen werden Datensätze „deaktiviert“ (ausgeblendet, aber erhalten) und können wieder aktiviert werden. Über einen Filter „auch inaktive anzeigen“ sind sie sichtbar.
• Rechte: „Leser“ kann nur ansehen; „Beschaffung“ anlegen/bearbeiten; Deaktivieren/Löschen nur „Admin“. Jede Änderung steht im Änderungsprotokoll (mit Benutzer und Zeit).
• Umfangreiche Tests abgesichert (110 grün).

Beim Öffnen einer Bestellung gibt es jetzt unter der Hauptmenüleiste ein Untermenü mit den Punkten Übersicht, Lieferinformation und Dokumente. Jeder Punkt öffnet ein Fenster (Modal).

• Übersicht (fertig): zeigt die wichtigsten Angaben der Bestellung übersichtlich gruppiert – Bestellnummer, Datum, Status, Lieferant, Gegenstand/Menge/Art, Beträge (netto/brutto), Bearbeiter/in, Vergabeart, Förderprogramm, Besitzergruppe und Bemerkung.
• Lieferinformation und Dokumente sind als Platzhalter bereits vorhanden und werden in den nächsten Schritten (Teilpaket 2 bzw. 3/4) mit Inhalt gefüllt.
• Bestehende Ansichten (Detail-Karten, Dokumente-Tabelle, Änderungsprotokoll) bleiben unverändert.

Der zweite Punkt des Untermenüs einer Bestellung, Lieferinformation, ist jetzt gefüllt. Das Fenster zeigt drei Bereiche:

• Lieferanschrift: die Schule aus dem Stamm (Name/Kürzel, Adresse, Telefon, E-Mail) oder – falls so erfasst – eine freie Lieferadresse.
• Ansprechpartner: die zur Schule hinterlegten aktiven Kontakte (Name, Funktion, Telefon, E-Mail). Bei freier Lieferadresse erscheint ein Hinweis, da Ansprechpartner über die Schule gepflegt werden.
• Rechnungsanschrift: Hinweis „Wie Lieferanschrift„ – eine abweichende Rechnungsanschrift wird derzeit nicht erfasst.

Das Untermenü einer Bestellung (Übersicht, Lieferinformation, Dokumente) öffnet die Inhalte jetzt direkt auf der Seite als Registerkarten (Tabs) – nicht mehr als eingeblendetes Fenster (Modal) mit abgedunkeltem Hintergrund.

• Übersicht (Standard) zeigt die Detailangaben der Bestellung.
• Lieferinformation zeigt Lieferanschrift, Ansprechpartner und Rechnungsanschrift.
• Dokumente zeigt die vorhandene Dokumentenliste (wird in den nächsten Schritten ausgebaut).
• Das Änderungsprotokoll bleibt unterhalb der Registerkarten sichtbar.

Der Tab Dokumente einer Bestellung zeigt jetzt die Dokumente der Bestellung und erlaubt das Hochladen direkt auf der Seite.

• Liste aller Dokumente in zeitlicher Reihenfolge – umschaltbar zwischen „neueste zuerst“ und „älteste zuerst„. Je Eintrag: Art, Bezeichnung, Datum, hochladende Person, Prüfsumme (gekürzt) und Öffnen/Entfernen.
• Hochladen (nur für berechtigte Rollen): Auswahl der Dokument-Art, Bezeichnung und PDF-Datei. Nach dem Hochladen erscheint das Dokument sofort in der Liste.
• Feste Dokument-Arten (8): Angebot, Auftragsbestätigung, Lieferschein, Rechnung, Gutschrift, Mahnung, Zahlungsbeleg, Sonstiges.
• Rechts ist bereits Platz für den Dokumentenbaum, der im nächsten Schritt (Teilpaket 4) folgt.

Im Dokumente-Tab gibt es rechts jetzt einen Dokumentenbaum – wie der „Belegfluss“ in großen Systemen. Ganz oben steht die Bestellnummer als Wurzel, darunter hängen alle Dokumente des Vorgangs.

• Dokumente lassen sich untereinander verknüpfen: ein Dokument kann einem anderen Dokument derselben Bestellung untergeordnet werden (z. B. die Rechnung unter das zugehörige Angebot). Es wird eingerückt darunter angezeigt.
• Die Verknüpfung ist eine Referenz, keine Kopie – jedes Dokument erscheint genau einmal.
• „Verknüpfung lösen„ hängt ein Dokument wieder direkt an die Bestellung.
• Ringschlüsse (Zyklen) sind ausgeschlossen, und man kann nur Dokumente derselben Bestellung verknüpfen. Verknüpfen/Lösen ist Berechtigten vorbehalten und wird im Änderungsprotokoll festgehalten.

Damit ist die an der Bestellnummer verankerte Belegkette (Teilpakete 1–4) vollständig – die Grundlage für die spätere automatische Zuordnung von E-Mail-Anhängen.

Die Startseite ist jetzt ein persönliches Dashboard: statt der wiederholten Navigations-Knöpfe zeigt sie Widgets mit nützlichen Informationen. Die Hauptnavigation bleibt oben in der Menüleiste.

• Bearbeiten-Modus über den Knopf „Dashboard bearbeiten“: Widgets lassen sich per Ziehen (am Kopf) verschieben und in der Größe ändern. Außerhalb des Bearbeiten-Modus ist die Anordnung fixiert.
• Die Anordnung wird pro Nutzer gespeichert und ist nach dem Neuladen wieder da (automatisches Speichern nach Änderungen und beim Beenden des Bearbeiten-Modus).
• Erste Widgets: „Willkommen„, „Neueste Bestellungen“ (nur mit Leserecht) und „Info„. Weitere Widgets folgen im nächsten Schritt.
• Technisch: die Rasterbibliothek GridStack.js liegt lokal auf dem Server (kein Internet-Abruf nötig).

Das Dashboard bekommt einen Widget-Katalog. Im Bearbeiten-Modus lassen sich jetzt Widgets frei hinzufügen und wieder entfernen; alle Widgets zeigen nur Daten, die der angemeldete Nutzer sehen darf.

• Knopf „+ Widget hinzufügen“ (nur im Bearbeiten-Modus) öffnet den Katalog. Ein Klick fügt das Widget ins Raster ein. Über das ✕ oben rechts an jeder Karte wird ein Widget wieder entfernt.
• Neue Widgets: Schnellzugriff (Verknüpfungen zu häufigen Aktionen wie „Neue Bestellung„), Meine offenen Freigaben (Ihnen zugewiesene, noch offene Rechnungsvorgänge), Neueste Bestellungen, Meldepflicht über 25.000 €, 3-Monats-Liste fürs Rechnungsprüfungsamt, Kennzahlen (Bestellungen je Jahr), Notiz (frei beschreibbarer Textblock) und Projekt-Wiki (Verknüpfung hierher).
• Der Notiz-Text wird mit dem persönlichen Layout gespeichert und ist nach dem Neuladen wieder da.
• Alle Widget-Daten sind rechtegefiltert: Wer z. B. kein Leserecht hat, sieht statt der Daten einen Hinweis.

Das Dashboard kann jetzt unter einem Namen gespeichert werden. So lassen sich mehrere Anordnungen vorhalten und bei Bedarf wieder laden.

• Neuer Knopf „Layouts“ öffnet ein Panel mit den Aktionen: Aktuelles Layout speichern unter …, Laden, Löschen und Als Standard setzen.
• Laden übernimmt die gespeicherte Anordnung in das persönliche Dashboard; die Seite wird anschließend neu aufgebaut.
• Ein Layout kann als persönlicher Standard markiert werden (immer genau eines). Ist das Dashboard leer, wird dieser Standard als Grundlage verwendet.
• Jedes Layout gehört genau seinem Ersteller; fremde Layouts sind nicht zugänglich. Das Teilen von Layouts mit anderen folgt im nächsten Schritt (globale Layouts).

Layouts können jetzt geteilt werden. Damit ist das Dashboard vollständig einrichtbar – persönlich und organisationsweit.

• Global freigeben: Jeder kann ein eigenes Layout für alle sichtbar machen (und die Freigabe wieder zurückziehen).
• Der Bereich „Globale Layouts„ zeigt alle freigegebenen Layouts. Über Übernehmen kopiert man ein solches Layout in sein eigenes Dashboard; die Vorlage bleibt dabei unverändert.
• Organisationsweiter Standard: Nur der Admin kann ein globales Layout zum org-weiten Standard machen. Neue Nutzer (bzw. Nutzer ohne eigenes Dashboard) sehen dann dieses Layout.
• Das globale Freigeben wird im Änderungsprotokoll festgehalten.

Die Startseite ist jetzt ein KPI-Kachel-Dashboard (Optik wie ein modernes Service-Dashboard): dunkle Kacheln mit Titel und großer Kennzahl, in der Hausfarbe Gelb als Akzent.

• Bedienung über die Kopfzeile: Links ≡ öffnet die gespeicherten Dashboards. Daneben steht der Name des aktuellen Dashboards. Rechts ⋮ schaltet den Bearbeiten-Modus ein und aus.
• Im Bearbeiten-Modus lassen sich Kacheln per Ziehen verschieben und vergrößern; es erscheinen die Aktionen + Kachel hinzufügen, Speichern und Speichern unter ….
• Erste KPI-Kachel „Bestellungen gesamt“ zeigt die Anzahl aktiver Bestellungen als große Zahl (nur mit Leserecht). Weitere Kacheln folgen im nächsten Schritt.
• Die Anordnung wird pro Nutzer gespeichert und ist nach dem Neuladen wieder da.

Der Katalog „+ Kachel hinzufügen„ bietet jetzt mehr Kacheln – als KPI-Zahlen und als Diagramm.

• Neue KPI-Kacheln: „Meine offenen Freigaben (Zahl)“ (große Zahl der Ihnen zugewiesenen offenen Vorgänge) und „Vorgänge je Status„ (Anzahl je Status im Rechnungs-Workflow).
• Diagramm-Kachel „Bestellungen je Jahr“: Balkendiagramm in der Hausfarbe Gelb (Bibliothek Chart.js, lokal auf dem Server – kein Internet nötig).
• Alle Kacheln zeigen weiterhin nur Daten, die der angemeldete Nutzer sehen darf.
• Bereits vorhandene Kacheln (Neueste Bestellungen, Meldepflicht über 25.000 €, 3-Monats-Liste, Schnellzugriff, Notiz, Projekt-Wiki, Kennzahlen) bleiben verfügbar.

Man kann jetzt mehrere Dashboards führen, über ≡ auswählen und gezielt speichern.

• ≡ (oben links) zeigt die gespeicherten Dashboards. Ein Klick auf „Laden„ öffnet das gewählte Dashboard; sein Name erscheint in der Kopfzeile und es ist im Panel als „Aktuell“ markiert.
• Im Bearbeiten-Modus (⋮): Speichern aktualisiert das gerade geladene Dashboard. Speichern unter … legt aus der aktuellen Anordnung ein neues Dashboard an.
• Gehört ein geladenes Dashboard jemand anderem (kommt mit den globalen Dashboards), ist „Speichern„ gesperrt – man legt mit „Speichern unter …“ eine eigene Kopie an.
• Weiterhin möglich: ein Dashboard löschen oder als persönlichen Standard setzen.

Dashboards lassen sich jetzt teilen. Damit ist das neue KPI-Dashboard vollständig.

• In der ≡-Auswahl gibt es die Abschnitte „Meine Dashboards„ und „Globale Dashboards“.
• Global freigeben: Jeder kann ein eigenes Dashboard für alle sichtbar machen (und die Freigabe zurückziehen). Es erscheint dann bei allen unter „Globale Dashboards„.
• Laden/Übernehmen: Ein globales Dashboard lässt sich laden; sein Name steht dann oben. Da es jemand anderem gehört, ist „Speichern“ gesperrt – mit „Speichern unter …„ legt man eine eigene Kopie an (die Vorlage bleibt unverändert).
• Organisationsweiter Standard: Nur der Admin kann ein globales Dashboard zum org-weiten Standard machen. Neue Nutzer erhalten dieses Dashboard automatisch.

Die Auswahl der gespeicherten Dashboards (Knopf ≡ oben links) ist jetzt ein übersichtliches Aufklapp-Menü.

• Ganz oben „＋ Neu“ → legt ein leeres Dashboard an und öffnet gleich den Bearbeiten-Modus zum Befüllen.
• Darunter die Liste der Dashboards. Das aktive Dashboard ist hervorgehoben und mit einem Häkchen ✓ markiert.
• Zwei Abschnitte: Meine Dashboards und Globale Dashboards. Je Eintrag gibt es kompakte Aktionen (als Standard setzen, freigeben/zurückziehen, löschen; beim Admin zusätzlich „org-weiter Standard„).
• „Speichern unter …“ blendet ein kleines Namensfeld ein.

Die Kopfzeilen-Knöpfe ≡ (Dashboard-Auswahl) und ⋮ (Bearbeiten) reagierten nicht auf Klicks. Das ist behoben.

• Ursache: ein Tippfehler im Dashboard-Skript – ein gerades Anführungszeichen („) statt der typografischen Variante („…“) beendete eine Textzeile vorzeitig. Dadurch war das gesamte Skript fehlerhaft und kein Knopf funktionierte mehr.
• Die lokal abgelegten Bibliotheken (GridStack, Chart.js) waren nicht die Ursache – sie wurden korrekt geladen.
• Jetzt: ≡ öffnet/schließt wieder das Auswahlmenü, ⋮ schaltet den Bearbeiten-Modus.
• Zusätzlich verhindert eine neue automatische Prüfung, dass sich ein solcher Skriptfehler erneut einschleicht.

Zwei kleine Verbesserungen am KPI-Dashboard, damit nichts abgeschnitten wird und das Speichern angenehmer ist.

• Mindestgröße je Kachel: Kacheln lassen sich nicht mehr so klein ziehen, dass Text abgeschnitten wird. Jede Kachel-Art hat eine sinnvolle Mindestgröße – eine reine Zahl-Kachel darf kleiner sein als eine Liste („Neueste Bestellungen„) oder das Diagramm. Bei Mindestgröße bleiben Titel und Inhalt vollständig lesbar; Diagramme skalieren mit.
• Speichern beendet den Bearbeiten-Modus: Nach einem Klick auf Speichern wird der Bearbeiten-Modus automatisch beendet (die Kacheln sind wieder fixiert) – man muss nicht erneut auf ⋮ klicken. „Speichern unter …“ verhält sich gleich und zeigt anschließend das neue Dashboard.

Die Bestellnummer ist jetzt keine einfache fortlaufende Zahl mehr (z. B. „2„), sondern folgt dem festen Nummernkonzept 522-JJJJ-NNNN (z. B. 522-2026-0001).

• 522 = fester Sachgebiets-Präfix, zentral konfigurierbar (BESTELLNUMMER_PRAEFIX in der .env, Standard 522) – nicht pro Bestellung änderbar.
• JJJJ = Jahr aus dem Bestelldatum (ohne Bestelldatum: das aktuelle Jahr beim Anlegen).
• NNNN = vierstellige laufende Nummer mit führenden Nullen, die pro Jahr neu bei 1 beginnt (2025 und 2026 zählen getrennt).
• Die Nummer wird einmalig beim Anlegen vergeben und bleibt danach unveränderlich (wie eine Rechnungsnummer/ein Aktenzeichen) – auch wenn später das Bestelldatum geändert wird. Im Bearbeiten-Formular wird sie schreibgeschützt angezeigt.
• Eindeutig und lückenlos pro Jahr, auch bei gleichzeitigem Anlegen durch mehrere Nutzer (Jahres-Zähler mit Zeilensperre SELECT … FOR UPDATE).
• Neuer Wartungsbefehl bestellnummern_neu_vergeben nummeriert vorhandene (Test-)Daten pro Jahr neu durch (Option –dry-run zeigt nur an).
• Abgesichert durch Tests (Format, Jahreswechsel-Reset, Unveränderlichkeit, Parallel-Anlegen, Umnummerierung); 194 Tests grün.

Eine neue Bestellung wird jetzt schlank eröffnet: Das Anlege-Formular fragt nur noch vier Felder ab, alles Weitere ergänzen Sie danach in der Detailansicht.

• Bestellnummer – automatisch (522-JJJJ-NNNN), schreibgeschützt; wird beim Speichern vergeben.
• Bestelldatum – mit dem heutigen Tag vorbelegt, frei änderbar.
• Titel – Pflichtfeld (technisch das bisherige Feld „Bezeichnung“, nur anders beschriftet).
• Beschreibung – optionaler Langtext (neues Feld, getrennt von der internen „Bemerkung„).

Weiteres Verhalten:

• Ein neuer Vorgang erhält den Status „In Bearbeitung“ (= offen) und erscheint sofort unter „Offene Vorgänge„.
• Nach dem Speichern öffnet sich direkt die Detailansicht des Vorgangs zum Ergänzen der übrigen Angaben (Lieferant, Beträge, Dokumente …).
• Der Menüpunkt „Meine Freigaben“ heißt jetzt „Vorgänge„ (Aufklappmenü) und enthält „Offene Vorgänge“, „Meine Vorgänge„ (die Ihnen zugeordneten) sowie weiterhin „Meine Freigaben“.
• Abgesichert durch Tests (nur vier Felder, Vorbelegung „heute„, Status/Weiterleitung, Rechte, Audit); 214 Tests grün.

Im hellen Modus blieben die Dashboard-Kacheln dunkel und der Text darin war kaum lesbar („dunkel auf dunkel“). Das ist behoben – die Kacheln passen sich jetzt in beiden Modi korrekt an.

• Ursache: Beim Bau der Kacheln waren dunkle Farben fest gesetzt, statt die Hell/Dunkel-Paare des Designs zu nutzen. Zusätzlich stellt die App-Regel für den gelben Akzent Zahlen/Links im hellen Modus auf Schwarz – auf der (fälschlich) dunklen Kachel wurden sie dadurch unsichtbar.
• Jetzt: Kacheln sind im hellen Modus weiß mit dunklem, gut lesbarem Text; im dunklen Modus unverändert dunkel mit hellem Text. Der gelbe Akzentstreifen am linken Kachelrand bleibt in beiden Modi.
• Die große KPI-Zahl ist in beiden Modi klar lesbar (hell: schwarz, dunkel: gelb) – kein Gelb auf Weiß.
• Auch die weiteren Kachel-Typen (Listen wie „Neueste Bestellungen„/„Meine offenen Freigaben“, das Diagramm und die Notiz) sowie die Bedienelemente des Dashboards wurden geprüft und angepasst. Das Balkendiagramm zieht seine Farben beim Umschalten der Modi automatisch nach.
• Rein optische Änderung; abgesichert durch die bestehenden Dashboard-Tests (69 grün).

Das Farbprofil der gesamten Anwendung wurde von Landkreis-Gelb auf das Freshservice-Profil in Blau umgestellt. Es ist eine reine Farb-Änderung – Aufbau, Bedienung und Funktionen bleiben unverändert, in allen Ansichten.

• Akzentfarbe Blau statt Gelb: Schaltflächen, aktive Menüreiter, Links, große Kennzahlen und Fokus-Rahmen sind jetzt blau (#2563eb); auf blauen Flächen ist die Schrift weiß und gut lesbar.
• Gelbe Sonderregeln entfernt: die Regel „schwarze Schrift auf Gelb„ und der gelbe Streifen unter der Kopfzeile sind weg; der farbige Zeilen-Hover in Tabellen ist nun ein dezenter Blau-Ton statt Gelb.
• Dunkelmodus wie Freshservice: die Flächen sind etwas dunkler/kühler (Near-Black); der helle Modus bleibt sauber und hell. Beide Modi sind gut lesbar.
• Logo bleibt unverändert als Wort-Bild-Marke auf weißer Box – es ist kein Bedien-Akzent.
• Rein optische Änderung; abgesichert durch die bestehenden Tests (257 grün). Optional offen: einzelne KPI-Kacheln in weiteren Farben – nur bei Bedarf.

Die Detailansicht einer Bestellung wurde grundlegend überarbeitet (sechs Schritte, jeweils getestet). Wichtige Grundsatzfragen wurden vorab abgestimmt.

• Ein einziger Status statt zweier: Die Bestellung hat jetzt einen Lebenszyklus (Offen → In Bearbeitung → Bestellt → Geliefert → Bezahlt → Abgewickelt), sichtbar als Fortschrittsleiste (Stepper) oben und als Kurz-Anzeige rechts. Kein widersprüchliches Doppel-Status mehr.
• Geführte Schritte statt Feld-Tippen: Pro Status eine hervorgehobene Aktion – „Bestellung senden“ (mit Von/An, setzt „Datum gesendet„ automatisch), „Lieferung erfassen“, „Rechnung ablegen„, „Abschließen“. Jeder Schritt wird im Änderungsprotokoll vermerkt.
• Keine doppelten Felder: Jedes Feld erscheint genau einmal. Die rechte Leiste zeigt sechs Kernangaben; die Reiter sind von fünf auf vier reduziert (Übersicht, Vergabe & Rechnung, Dokumente, Aktivität).
• Meldepflicht ab 25.000 € netto: Ein deutlich sichtbarer Warnhinweis erscheint bei hohen Beträgen; die Meldepflichten (Bekanntmachung/Statistik, Reviamt) lassen sich per Klick als erledigt markieren (mit Datum und Benutzer). Der Schwellwert ist jetzt in der Konfiguration einstellbar.
• Belegkette: Angebot → Bestellung → Rechnung als kompakte, klickbare Kette; fehlende Belege sind ausgegraut.
• Barrierefreiheit: durchgängig sichtbarer Tastatur-Fokus, bessere Kontraste beim roten „Deaktivieren„, Status/Ja-Nein immer mit Text + Symbol (nicht nur Farbe).
• Offen (dokumentiert): Positionszeilen je Bestellung – nur bei Bedarf und als eigenes Vorhaben.

Die Hauptnavigation ist von der oberen Leiste in eine linke Seitenleiste gewandert (wie in Freshservice). Es ändert sich nur das Layout – alle Seiten, Funktionen und Adressen bleiben gleich.

• Links: Startseite, Beschaffungsliste, Stammdaten, Vorgänge, Statistiken, Verwaltung – jeweils mit Symbol und Beschriftung. Der aktuelle Punkt ist blau hervorgehoben; Punkte mit Untermenü klappen auf.
• Oben links: Name der Anwendung und ein Umschalter (« / »). Damit lässt sich die Leiste einklappen (nur Symbole) und wieder ausklappen; die Untermenüs erscheinen dann als kleines Fenster neben dem Symbol. Die Einstellung merkt sich der Browser je Benutzer.
• Obere Leiste: nur noch Suche, „＋ Erstellen“, angemeldeter Benutzer/Abmelden, Hell-Dunkel-Umschalter und das Landkreis-Logo.
• Schmales Fenster: Die Navigation wird zur ausklappbaren Schublade (Knopf oben links).

Die Anwendung folgt jetzt dem tatsächlichen Ablauf einer Beschaffung.

• Eine Nummer von Anfang an: Aus der „Bestellnummer„ wird die Vorgangsnummer. Sie wird schon vergeben, wenn die Anforderung angelegt wird, und begleitet den Vorgang durchgehend – mit ihr wird das Angebot angefragt, die Bestellung ausgelöst, der Lieferschein und die Rechnung zugeordnet. Format und vorhandene Nummern bleiben unverändert (522-JJJJ-NNNN).
• Stationen statt freier Status: Angelegt → In Genehmigung → In Beschaffung → (Angebot angefordert/geprüft) → Beauftragt → Auftragsbestätigung geprüft → Lieferung offen → Wareneingang → Rechnung erfasst → Drei-Wege-Prüfung (ggf. Rechnungsklärung) → Zur Zahlung → Bezahlt → Archiviert. Stationen lassen sich nicht überspringen; jeder Schritt wird mit Person und Zeitpunkt protokolliert.
• Rollen: Neu sind Anforderer, Genehmiger, IT-Administrator (Wareneingang) und Buchhaltung. In der Detailansicht sieht man nur die Knöpfe für die Schritte, für die man zuständig ist. Die Rollen müssen den Personen noch zugewiesen werden (Verwaltung → Benutzer → Gruppen).
• Genehmigung mit Vier-Augen-Prinzip: Wer eine Anforderung erfasst hat, kann sie nicht selbst genehmigen. Eine Ablehnung ist nur mit Begründung möglich; der Anforderer wird per E-Mail informiert und sieht den Grund am Vorgang.
• Der Status ist nicht mehr im Bearbeiten-Formular – er ändert sich ausschließlich über die Prozess-Knöpfe.

Der Ablauf wurde an Ihre Vorgaben angepasst. Zwei wichtige Änderungen gegenüber der ersten Fassung:

• Keine Genehmigung mehr im System. Die Budget-/Bedarfsfreigabe klären Sie mündlich mit dem Vorgesetzten. Die Status „In Genehmigung“/„Abgelehnt„, die Rolle „Genehmiger“ und das Vier-Augen-Prinzip sind entfallen.
• Schritte dürfen übersprungen werden. Der Prozess zwingt Sie zu nichts: Bei Direktbeauftragung startet der Vorgang gleich bei „Beauftragt„ (kein Angebot nötig), optionale Stationen können Sie überspringen. Gesperrt sind nur Rückschritte und unsinnige Sprünge (z. B. „Bezahlt“ ohne erfasste Rechnung).

Der Weg im Überblick: Angelegt → Angebotsphase → Angebot ausgewählt & freigegeben → Beauftragt → Auftragsbestätigung geprüft → Lieferung offen → Wareneingang → Rechnung erfasst → Drei-Wege-Prüfung (ggf. Rechnungsklärung) → Zur Zahlung → Bezahlt → Archiviert. Zusätzlich: Abgebrochen (nur mit Begründung; der Anforderer wird per E-Mail informiert).

• Beim Anlegen wählen Sie den Weg: „Anforderung„ oder „Direktbeauftragung“. Die Vorgangsnummer wird in beiden Fällen sofort vergeben.
• Angebotsauswahl (neu): Liegen Angebote am Vorgang, wählt nur der IT-Administrator eines aus – auf Wunsch mit Auswahlgrund – und gibt den Vorgang damit zur Beauftragung frei.
• Übersprungene Stationen sind in der Fortschrittsleiste gestrichelt mit „–„ markiert; jeder Schritt steht mit Person und Zeitpunkt im Änderungsprotokoll.
• Rollen: Anforderer, Beschaffung/Backoffice, IT-Administrator, Buchhaltung, Rechnungsprüfer. Bitte den Personen zuweisen (Verwaltung → Benutzer → Gruppen) – ohne Rolle erscheinen die Prozess-Knöpfe nicht.

Die obere Leiste hat drei neue Elemente (nach Freshservice-Vorbild, aber auf unseren Prozess zugeschnitten):

• Glocke mit Zähler: Sie sehen auf einen Blick, wie viele Benachrichtigungen ungelesen sind. Im Klapp-Fenster stehen die neuesten zuerst – mit Text, Vorgangsnummer und Zeitpunkt. Ein Klick öffnet den Vorgang und markiert die Nachricht als gelesen; „Alle als gelesen markieren“ räumt auf. Jeder sieht nur seine eigenen Benachrichtigungen.
• Wann kommt eine Benachrichtigung? Beim Statuswechsel eines Vorgangs: „Ein Angebot wartet auf Ihre Auswahl„ (an den IT-Administrator), „Wareneingang zu prüfen“ (IT-Administrator), „Rechnung zu prüfen„ (Rechnungsprüfer/Buchhaltung) sowie „Neuer Status …“ an den Anforderer bzw. die Bearbeiterin des Vorgangs. Weitere Anlässe lassen sich leicht ergänzen.
• Benutzermenü (Initialen-Avatar): Name und E-Mail, Profileinstellungen (Anzeigename, E-Mail), Passwort ändern, Hell/Dunkel-Umschaltung und Abmelden. Unten dezent Datenschutz und Impressum. (Sobald die Anmeldung über das Active Directory läuft, verschwindet „Passwort ändern„ automatisch.)
• Hilfe „?“: führt direkt in dieses Projekt-Wiki.

Zusätzlich: Auftragsart nach Wertgrenzen. Aus dem Netto-Betrag schlägt die Anwendung den Weg vor – Direktbeauftragung bis 2.000 €, Angebotsbeauftragung bis 200.000 €, darüber Vergabeauftrag. Der dazu passende nächste Schritt steht in der Detailansicht vorn. Die Wertgrenzen sind einstellbar (ohne Programmierung).

Jeder Vorgang hat jetzt einen Reiter „Genehmigungen„. Damit lässt sich eine Freigabe geordnet einholen – von der einfachen Angebotsfreigabe durch den IT-Administrator bis zu mehrstufigen Abnahmen.

• Antrag auf Genehmigung: Sie benennen einen oder mehrere Genehmiger, geben der Gruppe einen Namen (z. B. „IT-Abnahme“), legen fest, wer genehmigen muss – Jeder (alle müssen zustimmen) oder Einer reicht – und schreiben optional dazu, worum es geht.
• Die Genehmiger werden benachrichtigt (Glocke und E-Mail) und entscheiden im Reiter mit Genehmigen oder Ablehnen, jeweils mit einer Nachricht/Begründung. Es darf nur entscheiden, wer auch benannt wurde – und nur einmal.
• Mehrere Genehmigungsgruppen je Vorgang sind möglich. Wie sie zusammen zählen, legt die Regel „Genehmigen, wenn …„ fest: *Alle Gruppen genehmigen*, *Jegliche Gruppe genehmigt*, *Mehrheit der Gruppen* oder *Zuerst antwortende Gruppe entscheidet*. Für den Alltag genügt meist eine Gruppe.
• Der Status rechnet sich selbst aus – aus den Einzelentscheidungen und den Regeln. Er kann also nie im Widerspruch zu den Entscheidungen stehen. Das Ergebnis steht als Banner über der Fortschrittsleiste: „Genehmigung liegt vor“ bzw. „abgelehnt„. Der Prozessstatus wird dadurch nicht automatisch weitergeschaltet – Sie behalten die Hand am Steuer.
• Verwalten: Über das „…“-Menü an der Gruppe lässt sie sich bearbeiten (solange noch niemand endgültig entschieden hat) oder stornieren (dann sind keine Entscheidungen mehr möglich, und die Gruppe zählt nicht mehr mit). Das dürfen nur der Ersteller oder ein Admin. Alles steht im Änderungsprotokoll.
• Wichtig: Ein Genehmiger braucht mindestens die Rolle Leser (Verwaltung → Benutzer → Gruppen) – sonst darf er den Vorgang nicht öffnen, auf dem er entscheiden soll.

Die Detailseite eines Vorgangs ist deutlich ruhiger geworden, und ein Vorgang lässt sich jetzt wirklich löschen.

• Kopf: Oben stehen nur noch der Titel und zwei Symbole – Bearbeiten (Stift) und Löschen (roter Papierkorb). Die Prozess-Knöpfe sind nach rechts gewandert.
• Rechte Spalte: drei aufklappbare Karten – „Status & nächster Schritt„ (aktueller Status, der passende nächste Schritt als Knopf, alles Weitere im Menü „Weitere Schritte“), „Eigenschaften„ (Vorgangsnummer, Auftragsart, Lieferant, Beträge …) und „Verknüpfungen“ (Belege verknüpfen und ansehen).
• Löschen (neu): „Deaktivieren„ gibt es nicht mehr. Wer löscht, muss zur Sicherheit die Vorgangsnummer eintippen; danach ist der Vorgang sofort verschwunden – für etwa 30 Sekunden kann man ihn über „Rückgängig“ zurückholen. Danach ist er endgültig weg, mit Angeboten, Genehmigungen, Belegen und Rechnungsdaten dieser Anwendung. Die Belege in Regisafe bleiben unberührt. Das Änderungsprotokoll bleibt ebenfalls erhalten. Löschen darf nur die Rolle Admin.
• Weniger Erklärtext: Lange Hinweise in der Maske sind gekürzt; Erklärungen stehen als kleines ⓘ-Symbol (Tooltip) oder als Link „Mehr im Wiki →„ dort, wo sie hingehören – hier im Wiki.
• Dokumente: PDFs lassen sich per Drag & Drop in das Feld ziehen (mit Fortschrittsanzeige); Dateityp und Größe werden vorab geprüft.
• Fristen: Bei „Meldung Reviamt (3-Monats-Liste)“ steht jetzt die Frist (Bestelldatum + 3 Monate). Bleiben weniger als 14 Tage – oder ist die Frist vorbei –, wird sie rot.

Im Filter (rechte Leiste) zeigt der Reiter „Basisfilter„ jetzt alle Filterfelder dauerhaft an.

• Die Suchleiste „Suchfelder …“ im Basisfilter wurde entfernt. Man muss nichts mehr suchen oder einblenden – Schule, Lieferant, Status, Rechnung, Jahr, Art, Vergabeart, Förderprogramm, Besitzergruppe, Betrag, Bestelldatum, Bearbeiter/in und Rechnungsvorgang stehen immer bereit.
• Die kleinen +/×-Symbole zum Ein-/Ausblenden und der Hinweis „Mit + …„ sind damit weg; die Meldung „Kein Filterfeld gefunden.“ kann nicht mehr auftreten.
• Der Erweiterte Filter bleibt unverändert – er ist ein Bedingungs-Builder mit eigener Feldauswahl je Zeile und hatte nie eine „Suchfelder„-Leiste.

Der Prozess eines Vorgangs hat jetzt nur noch vier Phasen:

• Angelegt – jeder neue Vorgang startet hier.
• Beauftragt – erreicht durch den Import eines Angebots oder einer Bestellbestätigung (Shop) (z. B. Amazon). Der Import bedeutet „beauftragt“.
• Rechnungsprüfung – erreicht durch das Ablegen der Rechnung; ein Admin prüft und gibt sie frei.
• Bezahlt – Ende des Prozesses.

Was sich ändert:

• Die Zwischenschritte Angebotsphase, Angebot ausgewählt & freigegeben, AB geprüft, Lieferung offen, Wareneingang und Rechnung erfasst gibt es nicht mehr – weder im Statusbalken (Stepper) noch in Filtern oder Auswahllisten.
• Automatisch: Lädt man ein Angebot/eine Bestellbestätigung hoch, springt der Vorgang auf „Beauftragt„; lädt man die Rechnung hoch, auf „Rechnungsprüfung“. Ein manueller Weg bleibt unter „Weitere Schritte„.
• Rechnung freigeben (Phase „Rechnungsprüfung“ → „Bezahlt„) dürfen nur Administratoren.
• Neuer Dokumenttyp „Bestellbestätigung (Shop)„ beim Hochladen.
• Der frühere separate Rechnungs-Freigabe-Workflow (Seite „Meine Freigaben“, Rolle „Freigeber“) ist entfallen; die Rolle „Freigeber„ wird entfernt.

Bestehende Vorgänge wurden automatisch auf die neuen Phasen umgestellt.

Der Dialog „Neue Bestellung“ ist deutlich einfacher: Es sind nur noch vier Angaben nötig.

• Bestellnummer – wird automatisch vergeben (Format 522-JJJJ-NNNN) und im Dialog nur angezeigt, nicht editierbar.
• Bestelldatum – vorbelegt mit dem heutigen Tag, änderbar.
• Titel – Pflichtfeld, kurze Bezeichnung der Bestellung.
• Beschreibung – optional.

Alle weiteren Angaben (Lieferant, Beträge, Vergabeart …) werden erst später im Vorgang gepflegt. Die frühere Auswahl „Weg„ (Anforderung / Direktbeauftragung) entfällt – jeder neue Vorgang startet bei „Angelegt“; eine Direktbeauftragung entsteht durch den Import einer Bestellbestätigung (siehe Version 0.19.0).

Nummern werden wiederverwendet: Wird ein Vorgang abgebrochen oder gelöscht, bevor er bezahlt ist, wird seine Nummer wieder frei und beim nächsten neuen Vorgang (niedrigste zuerst) erneut verwendet. Das ist so umgesetzt, dass auch bei zwei gleichzeitigen Nutzern nie dieselbe Nummer doppelt vergeben wird. Ein bezahlter Vorgang behält seine Nummer dauerhaft.

Betrifft die Lesbarkeit der Oberfläche (Vorgabe BITV 2.0 / WCAG AA: Text muss sich mindestens im Verhältnis 4,5:1 vom Hintergrund abheben).

Bisher wurde jede Farbe nur in der Kombination geprüft, für die sie gedacht war – nicht in der, in der sie versehentlich landen kann. Das ist jetzt umgestellt: Es gibt eine feste, mitversionierte Liste aller freigegebenen Farbkombinationen, und sie wird bei jedem Testlauf automatisch nachgerechnet. Eine vergessene Prüfung kann so nicht mehr passieren.

• Zwei tatsächliche Verstöße dabei gefunden und behoben: Die Beschriftung der Tabellenköpfe war sowohl im hellen als auch im dunklen Modus knapp zu blass (4,39:1 bzw. 4,06:1). Sie ist jetzt eine Spur kräftiger.
• Die Akzentfarbe Blau bleibt eine Fläche, keine Schriftfarbe. Als Schrift auf dunklem Grund wäre sie deutlich zu blass (bis herunter zu 1,99:1). Eine automatische Prüfung verhindert ab sofort, dass sie versehentlich als Schriftfarbe eingesetzt wird.
• Noch offen (bekannt, dokumentiert): die Beschriftung der blauen Dokumenttyp-Kennzeichen und des Filter-Chips ist knapp zu blass (4,24:1 hell / 4,07:1 dunkel); die hellste der drei Grautöne für Hinweistexte ist generell zu blass. Beides wird in einem eigenen Schritt entschieden.

Außerdem in dieser Sitzung: Die Fußzeile zeigte eine veraltete Versionsnummer an (0.22.0 statt 0.23.2). Ursache war ein veralteter Programmstand im Container – der Programmstand war seit mehreren Änderungen nicht neu ausgeliefert worden. Neu gebaut und ausgerollt; die Fußzeile zeigt jetzt wieder die tatsächlich laufende Version. Als Merkregel gilt: Eine Änderung ist erst dann in der Anwendung sichtbar, wenn der Container neu gebaut wurde – erkennbar an Version und Build-Kennung in der Fußzeile.

*(Nachtrag: Die Versionen 0.22.0 bis 0.23.2 sind hier nicht einzeln aufgeführt; sie stehen in der Datei CHANGELOG.md im Projektverzeichnis.)*

Sie können jetzt selbst bestimmen, welche Spalten die Beschaffungsliste zeigt. Die Einstellung hängt an Ihrem Benutzerkonto – sie gilt also an jedem Rechner, an dem Sie sich anmelden (vorher galt sie nur im jeweiligen Browser).

• Knopf „Spalten„ in der Leiste über der Liste, direkt neben „Exportieren“. Weicht Ihre Auswahl vom Standard ab, steht die Anzahl daneben.
• Standardmäßig sichtbar sind sieben Spalten: Nr., Bezeichnung, Status, Lieferant, Netto (€), Bestelldatum und die Aktionen. Elf weitere lassen sich zuschalten: Menge, Lieferadresse, Brutto (€), Rechnung, Datum gesendet, Art, Vergabeart, Förderprogramm, Besitzergruppe, Bearbeiter/in und Erstellt am.
• Nr., Bezeichnung und Aktionen lassen sich nicht abwählen – ohne sie wäre ein Vorgang nicht mehr zu erkennen oder zu bearbeiten. Sie sind im Dialog als Pflichtspalten gekennzeichnet.
• „Auf Standard zurücksetzen„ stellt jederzeit den Auslieferungszustand wieder her.
• Der Export folgt Ihrer Auswahl. Beim Klick auf „Exportieren“ können Sie zusätzlich „Alle Spalten„ wählen, wenn Sie einmal alles brauchen.

Bitte beachten: Wer die Spalten bisher schon angepasst hatte, findet zunächst wieder den Standardumfang vor. Die alte Einstellung lag nur im Browser und konnte nicht übernommen werden. Einmal neu einstellen genügt – danach bleibt sie dauerhaft und an jedem Arbeitsplatz erhalten.

Die Anwendung startet wieder im hellen Modus. Der dunkle Modus bleibt vollständig erhalten und lässt sich jederzeit über das Symbol ☀️/🌙 in der Kopfzeile einschalten.

• Wer den dunklen Modus bereits eingeschaltet hatte, behält ihn – es wird niemand umgestellt.
• Nur wer nie umgeschaltet hat, sieht ab sofort die helle Darstellung.
• Hinweis: Die Einstellung merkt sich der jeweilige Browser. An einem anderen Rechner startet die Anwendung deshalb zunächst wieder hell.

Ein Vorgang wird in der Adresszeile über seine Vorgangsnummer angesprochen – nicht mehr über eine interne Nummer, die niemandem etwas sagt.

• Vorher: /bestellungen/32/ — Jetzt: /bestellungen/522-2026-0013/
• Wer eine Adresse weitergibt oder in einer E-Mail sieht, erkennt sofort, um welchen Vorgang es geht. Es ist dieselbe Nummer, die auch auf Angebot, Bestellung, Lieferschein und Rechnung steht.
• Das gilt für alle Seiten am Vorgang: Bearbeiten, Löschen, Rückgängig, die Prozessschritte, Angebot anfordern und prüfen, Bestellung auslösen, Lieferverzug, Reklamation, Inventarisierung, Rechnungsfreigabe, Rechnungsprüfung, Meldepflicht, Gerät erfassen, Dokument hochladen und Genehmigung anfordern.
• Alte Lesezeichen auf /bestellungen/<Zahl>/ funktionieren nicht mehr und führen auf „Seite nicht gefunden“. Das ist so gewollt; es liegen bisher nur Testdaten vor. Bitte Lesezeichen neu setzen.
• Eine unbekannte Vorgangsnummer führt ebenfalls auf „Seite nicht gefunden„, nie auf einen Fehler.

Eine fachliche Änderung hängt daran: Ein abgebrochener Vorgang behält ab sofort seine Vorgangsnummer. Bisher wurde sie freigegeben und an den nächsten neuen Vorgang weitergereicht – dann hätte der abgebrochene Vorgang aber keine Adresse mehr und wäre nicht mehr aufrufbar. Freigegeben und wiederverwendet wird eine Nummer jetzt nur noch, wenn ein Vorgang vor der Bezahlung endgültig gelöscht wird. Praktisch heißt das: Abgebrochene Vorgänge hinterlassen eine Lücke im Nummernkreis – wie bei einem Aktenzeichen üblich.

Die Vorgangsnummer ist unverändert nicht änderbar, sobald sie vergeben ist.

• Der nginx, der die Domain ausliefert, muss den Pfad /dokuwiki an 192.168.20.50:8001 weiterleiten (Beispiel in docs/nginx-beispiel.conf).