500 lines
18 KiB
Markdown
500 lines
18 KiB
Markdown
# Aktualisierter Entwicklungsplan: Warenwirtschaft, Produktion & Produktbestand
|
|
|
|
> **Version:** 3.0 - Stand 13.05.2026
|
|
> **Prioritaet:** Anpassungsbriefing vom 27.04.2026 zuerst einarbeiten
|
|
> **Referenzen:** `entwicklungsplan.md`, `briefing-anpassungen-27-04-2026.md`, `feedback.md`, Screens unter `screens/`
|
|
|
|
---
|
|
|
|
## 1. Aktueller Ist-Stand
|
|
|
|
Laut bestehendem `entwicklungsplan.md` sind die Phasen 0 bis 5.1 umgesetzt:
|
|
|
|
- **Phase 0:** Bugfixes Produkt/INCI, Sync-Logik, Sortierung, Kopierfehler.
|
|
- **Phase 1:** INCI-Erweiterung, Rezepturfelder, Haltbarkeit, Produktkopie.
|
|
- **Phase 2:** Stammdaten-Module fuer Lagerorte, Lieferanten, Verpackung, Qualitaeten.
|
|
- **Phase 3:** Einkauf & Wareneingang als Zwei-Stufen-Workflow.
|
|
- **Phase 4:** Verpackung & Material am Produkt.
|
|
- **Phase 5:** Produktion MVP mit Chargen, Rezeptur-API und Packaging-Snapshot.
|
|
- **Phase 5.1:** Feedback-Korrekturen zu Menue, Rezeptur, Produktion und Verpackungsartikeln.
|
|
|
|
Noch offen aus dem alten Plan:
|
|
|
|
- **Phase 6:** Bestandsuebersichten & Alarme.
|
|
- **Phase 7:** Ausgang / Ausschuss.
|
|
- **Phase 8:** Rollen, Audit-Trail & Feinschliff.
|
|
- **Phase 9:** Einstellungen & Konfiguration.
|
|
- Offene Tests aus Phase 5.1, insbesondere Rezeptur/Hersteller-Rezeptur, Produktion kopieren/bearbeiten, aktive Produkte und Menue-Labels.
|
|
|
|
Das Anpassungsbriefing vom 27.04.2026 erweitert den Scope wesentlich. Deshalb wird vor den alten Phasen 6 bis 9 eine neue priorisierte Phase eingeschoben.
|
|
|
|
---
|
|
|
|
## 2. Neue Priorisierung
|
|
|
|
### Sofortige Reihenfolge
|
|
|
|
| Prioritaet | Phase | Titel | Status | Abhaengigkeit |
|
|
|------------|-------|-------|--------|---------------|
|
|
| P0 | 5.2 | Anpassungsbriefing 27.04.2026 | neu, sofort | Phasen 0-5.1 |
|
|
| P1 | 6 | Rohstoffbestand & Produktbestand | offen, angepasst | Phase 5.2 |
|
|
| P2 | 7 | Ausgang, manuelle Bestandsbewegungen & Historie | offen, erweitert | Phase 6 |
|
|
| P3 | 8 | Rechte, 2FA, Audit-Trail | offen, erweitert | Phase 5.2 + 7 |
|
|
| P4 | 9 | Einstellungen & Konfiguration | offen, erweitert | Phase 5.2 |
|
|
|
|
**Wichtig:** Funktionen aus Phase 6-9 duerfen erst final umgesetzt werden, wenn die neuen Stammdatenfelder, Produkt-Set-Logik und Produktbestandslogik aus Phase 5.2 geklaert und umgesetzt sind.
|
|
|
|
---
|
|
|
|
## 3. Phase 5.2: Anpassungsbriefing 27.04.2026
|
|
|
|
> **Ziel:** Alle neuen Anforderungen aus `briefing-anpassungen-27-04-2026.md` in das bestehende Warenwirtschaftsmodell integrieren, bevor Bestandsuebersichten und Historien final gebaut werden.
|
|
|
|
### 5.2.1 Einstellungen: UST-Saetze und Lieferzeiten
|
|
|
|
**Anforderungen**
|
|
|
|
- Neue konfigurierbare UST-Saetze, z. B. 19 %, 7 %.
|
|
- UST nicht hart im Code, sondern als Stammdatum/Setting verwalten.
|
|
- Lieferzeiten als frei definierbare Textwerte, z. B. `3-5 Tage`.
|
|
|
|
**Umsetzung**
|
|
|
|
- Neues Einstellungsmodul oder Erweiterung der bestehenden Warenwirtschafts-Einstellungen:
|
|
- `tax_rates`: Name, Prozentwert, aktiv.
|
|
- `delivery_times`: Textwert, aktiv, Sortierung.
|
|
- UST-Dropdowns in Einkauf und INCI nutzen diese Werte.
|
|
- Lieferzeit-Dropdowns/Textfelder bei Lieferant und INCI anbinden.
|
|
|
|
**Akzeptanzkriterien**
|
|
|
|
- SuperAdmin kann UST-Saetze und Lieferzeiten pflegen.
|
|
- Einkauf und INCI koennen nur aktive UST-Saetze auswaehlen.
|
|
- Lieferzeiten bleiben bewusst als Text flexibel.
|
|
|
|
### 5.2.2 Produkte: Einzelprodukt, Set und Hauptprodukt-Zuordnung
|
|
|
|
**Anforderungen**
|
|
|
|
- Produkte werden in zwei Klassen unterschieden:
|
|
- **Einzelprodukt:** hat Rezeptur, Hersteller-Rezeptur, Verpackung & Material, Warenwirtschaft.
|
|
- **Set:** hat keine eigene Rezeptur/Produktion, sondern besteht aus mehreren Einzelprodukten mit Menge.
|
|
- Im Produktformular wird eine Checkbox/Option eingebaut: `Ist Set`.
|
|
- Wenn `Ist Set` aktiv ist:
|
|
- Karten Rezeptur, Verpackung & Material und Warenwirtschaft ausblenden.
|
|
- Neue Karte `Set-Bestandteile` anzeigen.
|
|
- Modal mit auswaehlbaren Einzelprodukten, keine Sets.
|
|
- Produktbestand darf nur Hauptprodukte anzeigen.
|
|
- Child-/Set-Produkte muessen dem Hauptprodukt zugeordnet werden koennen, z. B. `50 x Bio Tattoocreme 15 ml`.
|
|
|
|
**Umsetzung**
|
|
|
|
- `products` erweitern:
|
|
- `is_set` boolean.
|
|
- `main_product_id` nullable FK auf `products`.
|
|
- optional `main_product_quantity` fuer Child-Produkte.
|
|
- Neue Pivot-Tabelle fuer Sets:
|
|
- `product_set_items`: `set_product_id`, `component_product_id`, `quantity`.
|
|
- Produktformular:
|
|
- Umschaltlogik fuer Einzelprodukt/Set.
|
|
- Set-Bestandteile wie bestehende Rezeptur-/Packaging-Modals aufbauen.
|
|
- Validierung:
|
|
- Set darf keine Sets enthalten.
|
|
- Set braucht mindestens einen Bestandteil.
|
|
- Einzelprodukt darf Rezeptur/Packaging/Warenwirtschaft pflegen.
|
|
|
|
**Akzeptanzkriterien**
|
|
|
|
- Ein Set kann aus mehreren Einzelprodukten bestehen.
|
|
- Beim Verkauf eines Sets werden die enthaltenen Einzelprodukte im Produktbestand reduziert.
|
|
- Set-Produkte erscheinen nicht als selbst produzierbare Produkte.
|
|
- Produktbestand zeigt nur Haupt-/Einzelprodukte, nicht die Child-/Set-Varianten.
|
|
|
|
### 5.2.3 Einkauf & Wareneingang erweitern
|
|
|
|
**Anforderungen**
|
|
|
|
- Einkauf bekommt UST-Dropdown.
|
|
- Brutto-Preis pro kg und Netto-Preis pro kg: eines der beiden Felder kann eingegeben werden, das andere berechnet sich automatisch.
|
|
- Ausgefuellten Einkauf duplizierbar machen.
|
|
- Aktionsicons Auge/Stift/Muelleimer in Tabellen groesser und mit mehr Abstand, iPad-tauglich.
|
|
|
|
**Umsetzung**
|
|
|
|
- `stock_entries` erweitern:
|
|
- `tax_rate_id` oder gespeicherter Snapshot `tax_rate_percent`.
|
|
- `price_per_kg_net`.
|
|
- `price_per_kg_gross`.
|
|
- Frontend-JS:
|
|
- Netto/Brutto anhand UST gegenseitig berechnen.
|
|
- Rundung einheitlich definieren.
|
|
- Copy-Route fuer Einkauf:
|
|
- Dupliziert Stufe-1-Felder.
|
|
- Laesst Chargennummer, MHD, Eingangsdaten und Status leer bzw. setzt wieder auf `pending`.
|
|
- Gemeinsame Tabellen-Aktionsklasse einfuehren:
|
|
- groessere Buttons.
|
|
- mehr Abstand.
|
|
- konsequent fuer Einkaufs-, Lieferanten-, Produktions-, Bestands- und Stammdatentabellen.
|
|
|
|
**Akzeptanzkriterien**
|
|
|
|
- Einkauf kann mit Netto oder Brutto angelegt werden.
|
|
- Beim Wechsel des UST-Satzes wird das Gegenfeld aktualisiert.
|
|
- Ein Einkauf kann fuer mehrere Kanister/Chargen komfortabel dupliziert werden.
|
|
- Tabellenaktionen sind auf dem iPad gut klickbar.
|
|
|
|
### 5.2.4 Lieferanten erweitern
|
|
|
|
**Anforderungen**
|
|
|
|
- Lieferant braucht Auswahl, ob Bestellung per Mail oder Online-Shop erfolgt.
|
|
- Je nach Auswahl soll spaeter in Rohstoffbestand/Bestellhilfe ein Link zum Shop oder ein Mail-Link erscheinen.
|
|
- Lieferant bekommt Lieferzeit als frei pflegbares Textfeld.
|
|
|
|
**Umsetzung**
|
|
|
|
- `suppliers` erweitern:
|
|
- `order_method` enum/string: `email`, `online_shop`.
|
|
- `order_email` nullable, falls abweichend von Kontakt-Mail.
|
|
- `order_url` nullable, falls abweichend von allgemeiner URL.
|
|
- `delivery_time` nullable string.
|
|
- Lieferantenformular:
|
|
- Radio/Select fuer Bestellart.
|
|
- passende Felder anzeigen.
|
|
- Spaetere Nutzung in Rohstoffbestand:
|
|
- Button `Bestellen` erzeugt `mailto:` oder oeffnet Shop-URL.
|
|
|
|
**Akzeptanzkriterien**
|
|
|
|
- Pro Lieferant ist erkennbar, wie bestellt wird.
|
|
- Rohstoffbestand kann daraus einen konkreten Bestell-Link ableiten.
|
|
- Lieferzeit des Lieferanten ist sichtbar und editierbar.
|
|
|
|
### 5.2.5 INCI erweitern
|
|
|
|
**Anforderungen**
|
|
|
|
- Pro INCI Mehrfachauswahl der Lieferanten, bei denen es gekauft werden kann.
|
|
- Pro INCI UST-Satz hinterlegen.
|
|
- Pro INCI optional eigene Lieferzeit; diese ueberschreibt die Lieferzeit des Lieferanten.
|
|
|
|
**Umsetzung**
|
|
|
|
- Neue Pivot-Tabelle:
|
|
- `ingredient_supplier`: `ingredient_id`, `supplier_id`, optional `preferred`, `supplier_sku`, `url`.
|
|
- `ingredients` erweitern:
|
|
- `tax_rate_id` oder Snapshot.
|
|
- `delivery_time` nullable string.
|
|
- INCI-Formular:
|
|
- Lieferanten-Mehrfachauswahl per Select2.
|
|
- UST-Dropdown.
|
|
- Lieferzeit-Textfeld.
|
|
|
|
**Akzeptanzkriterien**
|
|
|
|
- Ein INCI kann mehrere Lieferanten haben.
|
|
- Rohstoffbestand kann alle moeglichen Lieferanten mit Lieferzeit anzeigen.
|
|
- INCI-Lieferzeit ueberschreibt Lieferanten-Lieferzeit.
|
|
|
|
### 5.2.6 Produktion korrigieren
|
|
|
|
**Anforderungen**
|
|
|
|
- Neue Produktion optisch vereinfachen:
|
|
- weniger Linien.
|
|
- Ueberschriften `Charge` und `Menge` bei einzelnen Rohstoffen entfernen.
|
|
- bei Mengenangaben `g` hinter die Zahl.
|
|
- Chargen-Dropdown zeigt Lieferant, Charge und MHD:
|
|
- Beispiel: `Manske GmbH - DE-170722 - 30.09.2028`.
|
|
- `MHD`-Text nicht anzeigen.
|
|
- Nur Chargen anzeigen, von denen noch Bestand vorhanden ist.
|
|
- Basis fuer Produktion ist die Hersteller-Rezeptur.
|
|
- Fehler beim Hinzufuegen einer Charge beheben: Es duerfen nicht automatisch zwei neue Felder erscheinen.
|
|
- Wenn oben z. B. Stueckzahl geaendert wird:
|
|
- bestehende ausgefuellte Chargen/Mengen bleiben erhalten.
|
|
- nur Soll-Angaben in Gramm werden neu berechnet.
|
|
- iPad-Layout: Produktionsdatum und produzierte Stueckzahl duerfen nicht ueberlappen.
|
|
- Neuer Untermenuepunkt `Produktentwicklung` unter Produktion als Platzhalter.
|
|
|
|
**Umsetzung**
|
|
|
|
- `ProductionController::recipeJson()` auf Hersteller-Rezeptur als Basis umstellen.
|
|
- Chargenquery im `InventoryService` oder `ProductionService`:
|
|
- nur `received` Chargen.
|
|
- Restbestand pro Charge > 0.
|
|
- Label mit Lieferant, Chargennummer, Datum `d.m.Y`.
|
|
- JS fuer Chargen-Splitting korrigieren:
|
|
- genau eine neue Zeile pro Klick.
|
|
- vorhandene Eingaben beim Neuberechnen nicht ueberschreiben.
|
|
- Responsive Bootstrap-Grid fuer Kopfdaten der Produktion ueberarbeiten.
|
|
- Route/View fuer `Produktentwicklung` als Platzhalterseite:
|
|
- Hinweis: Konzept folgt.
|
|
- noch keine Bestandsbuchung.
|
|
|
|
**Akzeptanzkriterien**
|
|
|
|
- Produktion basiert auf Hersteller-Rezeptur.
|
|
- Chargenliste zeigt nur verfuegbare Chargen mit Lieferant und Datum.
|
|
- Aenderung der Stueckzahl zerstoert keine manuell eingetragenen Chargen.
|
|
- iPad-Darstellung ist nutzbar.
|
|
- Menuepunkt Produktentwicklung existiert sichtbar.
|
|
|
|
### 5.2.7 Rohstoffbestand als neuer Schwerpunkt
|
|
|
|
**Anforderungen**
|
|
|
|
- Neuer Menuepunkt `Rohstoffbestand`.
|
|
- Uebersicht zeigt, welche Rohstoffe im Lager sind.
|
|
- Muss Lieferanten, Lieferzeiten und Bestellmoeglichkeiten beruecksichtigen.
|
|
- Grundlage fuer spaetere Nachbestellung/Knappheitsanzeige.
|
|
|
|
**Umsetzung**
|
|
|
|
- Bestehende alte Phase 6 `Bestand Rohstoffe` wird inhaltlich auf `Rohstoffbestand` priorisiert.
|
|
- Spaltenvorschlag:
|
|
- INCI/Rohstoff.
|
|
- Qualitaet.
|
|
- Gesamtbestand.
|
|
- Bestand je Lagerort.
|
|
- reserviert/verbraucht durch Produktionen.
|
|
- Meldebestand oder berechneter Bedarf.
|
|
- Status.
|
|
- Lieferanten.
|
|
- Lieferzeit.
|
|
- Bestellaktion.
|
|
- Lieferzeitlogik:
|
|
- INCI-Lieferzeit vor Lieferanten-Lieferzeit.
|
|
- Bestellaktion:
|
|
- Online-Shop-Link oder Mail-Link je Lieferant.
|
|
|
|
**Akzeptanzkriterien**
|
|
|
|
- Rohstoffbestand zeigt reale Restbestaende aus Wareneingang minus Produktion/Ausgang.
|
|
- Nur Chargen mit Restbestand fliessen ein.
|
|
- Kritische Rohstoffe sind visuell markiert.
|
|
- Bestellweg ist direkt aus der Uebersicht erreichbar.
|
|
|
|
### 5.2.8 Produktbestand & Historie
|
|
|
|
**Anforderungen**
|
|
|
|
- Neuer Hauptmenuepunkt `Produktbestand`.
|
|
- Unterpunkt `Historie`.
|
|
- Produktbestand erlaubt einfache Ein- und Ausgaenge.
|
|
- Historie dokumentiert jeden Ein- und Ausgang revisionssicher, auch Verkauf ueber Shops und manuelle Eingaben.
|
|
- Screens zeigen:
|
|
- Suche.
|
|
- Checkbox `nur kritische anzeigen`.
|
|
- Bestand je Produkt.
|
|
- rote/gelbe Markierung bei kritischem Bestand.
|
|
- Aktionsbuttons `+`, `-`, `Produzieren`.
|
|
- Produktbestand zeigt nur Hauptprodukte.
|
|
|
|
**Umsetzung**
|
|
|
|
- Neue Tabellen:
|
|
- `product_stock_movements`: Produkt, Richtung `in/out`, Menge, Grund, Quelle, User, Datum, Referenz.
|
|
- optional `product_stock_thresholds` oder Felder an `products`: `min_product_stock`, `critical_product_stock`.
|
|
- Produktbestand wird berechnet:
|
|
- Summe Produktion/manuelle Eingaenge minus Verkauf/manuelle Ausgaenge/Set-Verbrauch.
|
|
- Manueller Eingang/Ausgang:
|
|
- Menge Pflicht.
|
|
- Grund Pflicht.
|
|
- Richtung Pflicht.
|
|
- Historie:
|
|
- filterbar nach Produkt, Quelle, Zeitraum, User.
|
|
- unveraenderbar bzw. Korrektur nur ueber Gegenbuchung.
|
|
- Shop-Verkaeufe:
|
|
- Produktbestand nach Bestellung reduzieren.
|
|
- Bei Sets Bestand der enthaltenen Einzelprodukte reduzieren.
|
|
|
|
**Akzeptanzkriterien**
|
|
|
|
- Produktbestand ist schnell pflegbar.
|
|
- Jede Bewegung steht in der Historie.
|
|
- Set-Verkaeufe reduzieren die enthaltenen Einzelprodukte.
|
|
- Kritische Produkte koennen gefiltert werden.
|
|
|
|
### 5.2.9 Nicht vorrätig mit Zeitangabe
|
|
|
|
**Anforderungen**
|
|
|
|
- Produkt bekommt Checkbox `Nicht vorrätig`.
|
|
- Zahl in Tagen wird hinterlegt.
|
|
- Im Shop erscheint z. B. `In ca. 14 Tagen wieder da!`.
|
|
- Die Zahl zaehlt automatisch runter und aktualisiert sich in der Bestellansicht.
|
|
|
|
**Umsetzung**
|
|
|
|
- `products` erweitern:
|
|
- `out_of_stock_until` date nullable oder `out_of_stock_days` plus Startdatum.
|
|
- Empfehlung: `out_of_stock_until`, weil daraus Resttage sauber berechnet werden.
|
|
- Produktformular:
|
|
- Checkbox.
|
|
- Tagefeld.
|
|
- beim Speichern `now()->addDays($days)`.
|
|
- Shopanzeige:
|
|
- Wenn Datum in Zukunft: Kaufbutton ersetzen/ergaenzen mit Hinweis.
|
|
- Resttage dynamisch berechnen.
|
|
- Scheduler optional:
|
|
- Status nach Ablauf automatisch deaktivieren oder Anzeige laeuft durch Datumslogik aus.
|
|
|
|
**Akzeptanzkriterien**
|
|
|
|
- Produkt kann zeitweise als nicht vorrätig markiert werden.
|
|
- Hinweis im Shop zeigt aktuelle Resttage.
|
|
- Nach Ablauf verschwindet der Hinweis automatisch.
|
|
|
|
### 5.2.10 Admin-Sicherheit: 2FA und blockbasierte Rechte
|
|
|
|
**Anforderungen**
|
|
|
|
- 2FA per Google Authenticator fuer Admins.
|
|
- Rechtevergabe pro Block:
|
|
- ansehen.
|
|
- bearbeiten.
|
|
- optional loeschen/freigeben.
|
|
- Mitarbeiter koennen Admins sein, aber nur ausgewaehlte Bereiche sehen/bearbeiten.
|
|
|
|
**Umsetzung**
|
|
|
|
- 2FA:
|
|
- Pruefen, ob bestehende Auth-Struktur mit `App\User` und Guard `user` erweitert wird.
|
|
- TOTP-Secret am User speichern.
|
|
- Setup-Flow fuer Admins.
|
|
- Login-Zwischenschritt fuer 2FA-Code.
|
|
- Rechte:
|
|
- Neues Berechtigungsmodell statt nur numerischem `admin`-Level fuer Warenwirtschaftsbloecke.
|
|
- Tabellen z. B. `admin_permission_blocks`, `admin_permission_user`.
|
|
- Bloecke: Produkte, Einkauf, Rohstoffbestand, Produktbestand, Produktion, Lieferanten, Einstellungen, Historie.
|
|
- Middleware/Gates fuer `view` und `edit`.
|
|
|
|
**Akzeptanzkriterien**
|
|
|
|
- Admin kann ohne 2FA nicht in geschuetzte Bereiche, sobald 2FA aktiviert ist.
|
|
- SuperAdmin kann pro Mitarbeiter Rechte je Block vergeben.
|
|
- Navigation zeigt nur erlaubte Bloecke.
|
|
- Bearbeiten ist getrennt von Einsehen steuerbar.
|
|
|
|
---
|
|
|
|
## 4. Angepasste offene Phasen nach 5.2
|
|
|
|
## Phase 6: Rohstoffbestand & Produktbestand
|
|
|
|
> **Status:** offen, erweitert durch Screens und Anpassungsbriefing.
|
|
|
|
### Inhalt
|
|
|
|
- `InventoryService` finalisieren.
|
|
- Rohstoffbestand mit Lieferanten-, Lieferzeit-, UST- und Bestellinformationen.
|
|
- Produktbestand mit Hauptproduktfilter, kritischen Markierungen, manuellen Bewegungen und `Produzieren`-Shortcut.
|
|
- Bestand pro Lagerort und Gesamtbestand.
|
|
- Kritisch-Filter analog Screen.
|
|
|
|
### Tests
|
|
|
|
- Bestandsberechnung Rohstoffe pro Charge und Lagerort.
|
|
- Nur Chargen mit Restbestand werden angezeigt.
|
|
- Produktbestand zeigt nur Hauptprodukte.
|
|
- Set-Verkauf reduziert Einzelproduktbestand.
|
|
- Kritisch-Filter zeigt nur Produkte/Rohstoffe unter Schwellwert.
|
|
|
|
## Phase 7: Ausgang, Bewegungen & Historie
|
|
|
|
> **Status:** offen, inhaltlich erweitert.
|
|
|
|
### Inhalt
|
|
|
|
- Alter `Ausgang / Ausschuss` bleibt fuer Rohstoffe/Verpackung relevant.
|
|
- Produktbestand bekommt eigene Bewegungslogik.
|
|
- Produktbestand-Historie als Finanzamt-/Audit-Archiv.
|
|
- Jeder manuelle Ein- und Ausgang braucht Grund, User und Datum.
|
|
|
|
### Tests
|
|
|
|
- Rohstoff-Ausgang reduziert Rohstoffbestand.
|
|
- Produkt-Ausgang reduziert Produktbestand.
|
|
- Historie dokumentiert alle Quellen: Produktion, Verkauf, manuell, Set.
|
|
- Manuelle Korrektur ohne Grund wird abgelehnt.
|
|
|
|
## Phase 8: Rollen, Audit-Trail, 2FA
|
|
|
|
> **Status:** offen, erweitert.
|
|
|
|
### Inhalt
|
|
|
|
- Bisheriger Audit-Trail bleibt Pflicht.
|
|
- Blockbasierte Rechte ersetzen fuer neue Module reine Level-Annahmen.
|
|
- 2FA fuer Admins.
|
|
- Bestehende Rollenlevel bleiben als Grundschutz erhalten, werden aber fuer Modulrechte verfeinert.
|
|
|
|
### Tests
|
|
|
|
- User mit Leserecht kann sehen, aber nicht speichern.
|
|
- User ohne Blockrecht sieht den Menuepunkt nicht.
|
|
- 2FA-Zwischenschritt greift fuer Admins.
|
|
- Audit-Log wird bei jeder Bestandsbewegung geschrieben.
|
|
|
|
## Phase 9: Einstellungen & Konfiguration
|
|
|
|
> **Status:** offen, erweitert.
|
|
|
|
### Inhalt
|
|
|
|
- UST-Saetze.
|
|
- Lieferzeiten.
|
|
- Bestandsalarm-E-Mail.
|
|
- Standard-Lagerort.
|
|
- Produktbestand-Schwellwerte, falls global sinnvoll.
|
|
- Optional: Standardtexte fuer `Nicht vorrätig`.
|
|
|
|
### Tests
|
|
|
|
- Nur SuperAdmin kann Einstellungen pflegen.
|
|
- UST-Saetze koennen deaktiviert, aber historische Werte weiterhin angezeigt werden.
|
|
- Lieferzeiten stehen in Lieferanten und INCIs zur Auswahl.
|
|
|
|
---
|
|
|
|
## 5. Offene Klaerungspunkte
|
|
|
|
- Soll `Nicht vorrätig` den Kauf komplett sperren oder nur einen Hinweis anzeigen?
|
|
- Wird Produktbestand beim Status `bezahlt`, `versendet` oder direkt bei Bestellung reduziert?
|
|
- Sollen Produktbestandsbewegungen auch Stornos/Retouren automatisch abbilden?
|
|
- Soll die blockbasierte Rechtevergabe nur fuer Warenwirtschaft/Produktmanagement gelten oder fuer alle Admin-Bereiche?
|
|
- Soll Produktentwicklung bereits Bestandsabzug erzeugen oder zunaechst nur ein Platzhalter-Menuepunkt sein?
|
|
- Soll ein Child-Produkt zwingend genau ein Hauptprodukt haben oder koennen mehrere Einzelprodukte in einem Verkaufsprodukt gebuendelt werden? Fuer echte Sets ist die Pivot-Loesung vorgesehen.
|
|
|
|
---
|
|
|
|
## 6. Empfohlene naechste Umsetzungsschritte
|
|
|
|
1. Datenmodell fuer `is_set`, Set-Bestandteile, Hauptprodukt-Zuordnung und Produktbestand finalisieren.
|
|
2. Einstellungen fuer UST-Saetze und Lieferzeiten umsetzen, weil Einkauf/INCI/Lieferanten davon abhaengen.
|
|
3. Lieferanten und INCIs um Bestellweg, Lieferzeit, UST und Lieferanten-Zuordnung erweitern.
|
|
4. Einkauf um Netto/Brutto/UST, Duplizieren und iPad-taugliche Aktionsbuttons erweitern.
|
|
5. Produktion auf Hersteller-Rezeptur, bessere Chargenlabels und stabile JS-Neuberechnung korrigieren.
|
|
6. Produktbestand mit Historie und manuellen Bewegungen bauen.
|
|
7. Rohstoffbestand mit Lieferanten-/Bestellinformationen bauen.
|
|
8. Danach alte Phasen 7-9 finalisieren: Ausgang, Audit, Rechte, 2FA, Einstellungen.
|
|
|
|
---
|
|
|
|
## 7. Grobe Aufwandsschaetzung
|
|
|
|
| Block | Aufwand |
|
|
|-------|---------|
|
|
| Einstellungen UST/Lieferzeiten | 1-2 Tage |
|
|
| Produkt Set-/Hauptproduktmodell | 3-5 Tage |
|
|
| Einkaufserweiterungen | 2-3 Tage |
|
|
| Lieferanten/INCI-Erweiterungen | 2-4 Tage |
|
|
| Produktionskorrekturen | 2-4 Tage |
|
|
| Rohstoffbestand | 4-6 Tage |
|
|
| Produktbestand + Historie | 5-8 Tage |
|
|
| Nicht vorrätig | 1-2 Tage |
|
|
| 2FA Admins | 3-5 Tage |
|
|
| Blockbasierte Rechte | 5-8 Tage |
|
|
| Tests & Feinschliff | 4-6 Tage |
|
|
|
|
**Neue Gesamtannahme fuer offene Arbeit:** ca. 6-9 Wochen bei einem Entwickler, abhaengig davon, wie tief Shop-Verkaeufe, Stornos und Rechtevergabe integriert werden sollen.
|