WIP-Schnappschuss vor Migration 2026-09-28 (uncommittete Änderungen von master)
This commit is contained in:
parent
5995c6791a
commit
dd968fb001
8 changed files with 87 additions and 405 deletions
7
.claude/settings.local.json
Normal file
7
.claude/settings.local.json
Normal file
|
|
@ -0,0 +1,7 @@
|
|||
{
|
||||
"permissions": {
|
||||
"allow": [
|
||||
"Bash(vendor/bin/pint --dirty)"
|
||||
]
|
||||
}
|
||||
}
|
||||
26
AGENTS.md
Normal file
26
AGENTS.md
Normal file
|
|
@ -0,0 +1,26 @@
|
|||
# Repository Guidelines
|
||||
|
||||
## Project Structure & Module Organization
|
||||
This is the Gruene Seele partner, e-commerce, and inventory application, using Laravel 11 and PHP 8.2+ (Docker uses PHP 8.4).
|
||||
|
||||
- `app/Http/` contains controllers and middleware; `app/Repositories/` and `app/Services/` hold business logic. Models live in `app/Models/`, with the user model at `app/User.php`.
|
||||
- `routes/web.php` defines main, promotion, and shop domain routes; `routes/api.php` contains API endpoints.
|
||||
- `resources/views/` holds Blade templates, `resources/lang/` translations, and `resources/assets/` JavaScript, Sass, and theme assets. `public/` serves web assets.
|
||||
- `database/` contains migrations, factories, and seeders; `tests/Unit/` and `tests/Feature/` contain automated tests.
|
||||
- `packages/digital-bird/shoppingcart/` is the Composer-autoloaded cart fork. `dev/` contains integrations and planning material; `docs/` includes inventory test guidance.
|
||||
|
||||
## Build, Test, and Development Commands
|
||||
- `composer install`: install locked PHP dependencies.
|
||||
- `php artisan serve --no-interaction`: run locally with configured database and domain settings.
|
||||
- `npm run dev`, `npm run watch`, `npm run prod`: build development assets, watch changes, or build production assets using Laravel Mix. Current `webpack.mix.js` references missing `resources/js/app.js` and `resources/sass/app.scss`; resolve entry points before expecting builds to pass.
|
||||
- `php artisan test --no-interaction`: run the test suites; add `--filter=ExampleTest` for a focused run.
|
||||
- `vendor/bin/pint --dirty`: format changed PHP files. `composer format` formats the full project; `pint.json` uses the Laravel preset and excludes `dev/`.
|
||||
|
||||
## Coding Style & Naming Conventions
|
||||
Use four-space PHP indentation, PascalCase classes, camelCase methods, and descriptive timestamped snake_case migrations. Follow neighboring Blade and JavaScript conventions. Keep controllers thin by delegating to repositories and services. Preserve the existing Laravel directory layout, including HTTP/console kernels, and use the `user` authentication guard.
|
||||
|
||||
## Testing Guidelines
|
||||
Pest 2 and PHPUnit are available; existing tests use PHPUnit classes named `*Test.php`. Put isolated logic tests in `Unit` and application behavior tests in `Feature`. `phpunit.xml` forces SQLite in-memory storage and array mail/cache drivers. Add regression coverage for behavior changes; no minimum coverage threshold is configured. Follow `docs/testleitfaden-wawi-2026-07-06.md` for inventory validation.
|
||||
|
||||
## Commit & Pull Request Guidelines
|
||||
Recent commits use German, topic-prefixed summaries, often with work-package IDs: `Warenwirtschaft: AP-34 — Varianten-Artikelnummer korrekt zuordnen`. Keep commits focused. PRs should explain the behavior change, link relevant issues or AP IDs, list validation results and migration/configuration steps, and include screenshots for UI changes. Exclude credentials and unrelated local edits.
|
||||
BIN
dev/dhl-for-woocommerce.zip
Normal file
BIN
dev/dhl-for-woocommerce.zip
Normal file
Binary file not shown.
Binary file not shown.
|
|
@ -1,5 +1,7 @@
|
|||
# AP-53: Prüfung der Mengenpräzision vom 10.09.2026
|
||||
|
||||
**Aktueller Stand nach Nachprüfung:** Die vier ursprünglichen Reproduktionsfälle sind behoben. Bei der zusätzlich eingeführten Rundung längerer Eingaben bleibt eine Abweichung zwischen Ampel und Server. Die unabhängige Verifikation und dieser neue Randfall stehen in **Abschnitt 7**. Abschnitte 1–5 dokumentieren den ursprünglichen Prüfstand, Abschnitt 6 die anschließende Umsetzung.
|
||||
|
||||
**Ergebnis: Die Umstellung auf drei Nachkommastellen funktioniert in den wesentlichen Buchungsabläufen, ist aber noch nicht durchgängig umgesetzt.** Vier konkrete Fehler wurden reproduziert: unterschiedliche Toleranzen in Formular und Backend, Ablehnung eines zulässigen Toleranzrandwerts, ganzzahlig gerundete Chargen-Hauptzeilen und unpräzise Ausschuss-Fehlermeldungen. AP-53 sollte deshalb noch nicht uneingeschränkt als fachlich abgenommen gelten.
|
||||
|
||||
Die vorhandene Suite ist grün: **378 Tests, 1.554 Assertions**. Zusätzliche Prüfungen bestätigen unter anderem genaue Milligramm-Buchungen, FEFO-Aufteilung, konsistente Gesamt-/Standort-/Chargenreste, deutsches Wiederöffnen von Entwurfsmengen und die ml-Umrechnung. Die grüne Suite allein erkennt die vier nachfolgenden Fehler jedoch nicht.
|
||||
|
|
@ -172,3 +174,55 @@ Alle vier reproduzierten Fehler sowie die Punkte 4.1–4.4 wurden am 10.09.2026
|
|||
| **4.4** Doku/Tests | ✅ erledigt | Hinweise-Text präzisiert (Übersichten ganzzahlig, Einzelwerte bis drei Stellen, Rundungs-/Untergrenzregel); Leitfaden §26 um Sockelrand-, Rundungs- und Chargenzeilen-Prüfschritte ergänzt; Sockelrand-Test vorhanden (AP53-02). Die Dev-Ausführung der Migration wurde am 09.09.2026 gegen die MySQL-Live-Kopie verifiziert (Spaltentypen `decimal(12,3)`, 53/78/7 Zeilen unverändert). |
|
||||
|
||||
Nicht Teil dieser Nacharbeit: MySQL-Grenzwerttest und Browser-/iPad-Abnahme (wie in Abschnitt 5 beschrieben, bleiben Teil der Live-Abnahme).
|
||||
|
||||
## 7. Unabhängige Nachprüfung der Korrekturen (10.09.2026)
|
||||
|
||||
**Ergebnis:** Die Korrekturen der vier ursprünglichen Reproduktionsfälle sind bestätigt. Die zusätzliche Änderung zur Normalisierung auf drei Nachkommastellen erzeugt jedoch einen weiteren Fall, in dem Ampel und Server unterschiedliche Ergebnisse liefern. Daher ist die Aussage „die vier konkreten Fehlerfälle sind behoben“ richtig; eine allgemeine Übereinstimmung der Ampel mit dem Server ist noch nicht vollständig erreicht.
|
||||
|
||||
**Prüfstand:** `6bd867cbe7cc00a6b2d6e34970cef69551cc5d76` einschließlich des vorhandenen Arbeitsverzeichnisses. Keine Änderung an Anwendungscode, bestehenden Tests, Migrationen oder Konfiguration. Ausschließlich dieser Bericht wurde ergänzt; bereits vorhandene fremde Änderungen wurden beibehalten.
|
||||
|
||||
### 7.1 Bestätigung der ursprünglichen Befunde
|
||||
|
||||
| Befund | Erneut geprüftes Verhalten | Ergebnis |
|
||||
|---|---|---|
|
||||
| AP53-01 – Alter Ampel-Sockel | Bei Soll 0,125 g und Ist 0,132 g zeigt das tatsächlich ausgeführte Formular jetzt **rot**; der Server lehnt den Abschluss ebenfalls ab. Toleranzverhältnis, Sockel und Vergleichsreserve stammen aus dem Service. | Ursprünglicher Fehlerfall **behoben**; zusätzlicher Rundungsfall siehe 7.2. |
|
||||
| AP53-02 – Exakter Sockelrand | Der HTTP-Abschluss mit Soll 0,020 g und Ist 0,025 g wird jetzt akzeptiert. Die vorhandene Regression prüft außerdem den unteren Rand und jeweils 0,001 g außerhalb. | **Behoben** |
|
||||
| AP53-03 – Chargen-Hauptzeile | Die konkret gerenderte Hauptzeile zeigt bei 0,125 g Rest jetzt **0,125 g**. Auch die Standortsumme wurde auf den Mengenformatierer umgestellt. | **Behoben** |
|
||||
| AP53-04 – Ausschuss-Fehlermeldungen | Angeforderte 0,005 g bei 0,004 g Rest werden korrekt abgelehnt und mit **0,005 / 0,004 g** erläutert. Requestpfade mit/ohne Charge sowie die erneute Controllerprüfung verwenden den Mengenformatierer. | **Behoben** |
|
||||
|
||||
### 7.2 AP53-N01 – Ampel berücksichtigt die neue Rundung längerer Eingaben nicht
|
||||
|
||||
**Priorität: P2 – Weiterhin widersprüchliche Freigabeanzeige bei ausdrücklich zugelassenen längeren Eingaben.**
|
||||
|
||||
**Fundstellen:** `resources/views/admin/inventory/productions/_scripts.blade.php:137` summiert die ungerundeten Ergebnisse von `parseGerman()`. `app/Services/ProductionService.php:826` rundet in `parseQuantity()` jetzt jede Ist-Menge auf drei Stellen, bevor der Service die Summen und deren Toleranz prüft.
|
||||
|
||||
Der gemeinsame Toleranzparameter und die Float-Vergleichsreserve sind korrekt eingeführt. Beide Seiten vergleichen bei vier oder mehr Nachkommastellen aber weiterhin unterschiedliche Mengen. Solche Eingaben sind nach der neuen Regel ausdrücklich zulässig und werden gerundet; es handelt sich nicht um einen absichtlich ungültigen Eingabeweg.
|
||||
|
||||
**Zwei unabhängig nachgestellte Beispiele:**
|
||||
|
||||
| Soll | Eingegebene Ist-Menge | Anzeige im ausgeführten Formular | Serververhalten |
|
||||
|---|---|---|---|
|
||||
| 0,125 g | 0,1314 g | **Rot**, weil ungerundet 0,0064 g Abweichung über der Toleranz von 0,00625 g liegen | Rundet auf **0,131 g**, akzeptiert und bucht diese Menge |
|
||||
| 0,0205 g | 0,0255 g | **Grün**, weil die ungerundete Abweichung genau 0,005 g beträgt | Rundet auf **0,026 g**; Abweichung zum Soll 0,0055 g, Abschluss wird abgelehnt |
|
||||
|
||||
Das zweite Beispiel verwendet eine zulässige Rezeptur-Sollmenge mit mehr als drei Stellen. Die Entscheidung, Sollmengen nicht pauschal auf die Ist-Auflösung zu runden, ist Teil der Nacharbeit und bleibt fachlich sinnvoll.
|
||||
|
||||
**Empfehlung:** Im Formular jede Ist-Zeile nach derselben definierten Dezimalregel wie im Backend normalisieren, danach summieren und gegen das unverändert präzise Soll vergleichen. Nicht erst die Gesamtsumme aller Zeilen runden, da dies vom serverseitigen Runden je Zeile abweichen kann. Die Regel und der tatsächlich zu buchende Wert sollten für den Anwender erkennbar sein. Alternativ wären längere Eingaben konsequent in beiden Schichten abzulehnen; das wäre jedoch eine Änderung der nun dokumentierten Eingaberegel.
|
||||
|
||||
**Abnahme:** Beide Tabellenfälle direkt in ein geladenes Formular eingeben und anschließend absenden. Ampel und Server müssen denselben Zustand bewerten. Ergänzend mehrere Chargenzeilen mit jeweils mehr als drei Nachkommastellen prüfen, damit die Reihenfolge „je Zeile runden → summieren → Toleranzvergleich“ übereinstimmt.
|
||||
|
||||
### 7.3 Prüfprotokoll
|
||||
|
||||
| Prüfung | Ergebnis |
|
||||
|---|---|
|
||||
| Gesamte vorhandene Suite: `php artisan test` | **384 Tests bestanden, 1.592 Assertions**, 6,06 s |
|
||||
| Unveränderte frühere PHP-Diagnosen: `/tmp/WawiAp53ProbeTest.php` | **7 Tests bestanden, 51 Assertions**, 0,406 s |
|
||||
| Unveränderte frühere DOM-Diagnosen: `/tmp/wawi-ap53-dom.cjs` | **8 Prüfungen bestanden, 0 fehlgeschlagen** |
|
||||
| Erweiterte PHP-Diagnosen: `/tmp/WawiAp53FollowupProbeTest.php` | **9 Tests bestanden, 63 Assertions**, 0,563 s; enthalten die sieben ursprünglichen Fälle und die beiden beobachteten serverseitigen Rundungsabläufe |
|
||||
| Erweiterte DOM-Diagnosen: `/tmp/wawi-ap53-followup-dom.cjs` | **10 Prüfungen: 8 bestanden, 2 fehlgeschlagen**; die beiden Fehlschläge betreffen die zwei Ausprägungen von AP53-N01 |
|
||||
|
||||
Die erweiterten PHP-Diagnosen sichern ab, welchen gerundeten Wert der Server tatsächlich akzeptiert bzw. ablehnt. Die zugehörigen DOM-Assertions verlangen die passende Ampelfarbe und schlagen deshalb in beiden neuen Fällen fehl. Die überlappenden früheren und erweiterten Testläufe sind nicht als voneinander unabhängige Testsummen zu zählen.
|
||||
|
||||
Alle zusätzlichen PHP-Prüfungen liefen mit `vendor/bin/phpunit -c phpunit.xml --do-not-cache-result` und SQLite `:memory:`. Die DOM-Prüfungen verwendeten erneut aus synthetischen Testdaten gerendertes HTML und Rezeptur-JSON; externe Ressourcen wurden nicht geladen. Prüfprogramme und Artefakte liegen außerhalb des Repositories unter `/tmp`. Die bekannte PHPUnit-Deprecation zur XML-Konfiguration besteht weiterhin und ist kein fachlicher Testfehler.
|
||||
|
||||
**Abnahmegrenze:** Die vier ursprünglichen Korrekturen sind verifiziert. AP53-N01 bleibt offen. Die zusätzlich in Abschnitt 6 beschriebenen Bereichs-/Auflösungsänderungen sind durch die vorhandene Suite nur in den dort getesteten Fällen abgedeckt; diese Nachprüfung bestätigt keinen vollständigen MySQL-Grenzwerttest oder Live-Rollout. Reale Browser-/iPad-Abnahme und die bereits festgehaltenen Betriebsnachweise bleiben separat erforderlich.
|
||||
|
|
|
|||
148
docs/Todos.md
148
docs/Todos.md
|
|
@ -1,148 +0,0 @@
|
|||
> **📁 HISTORISCH / VOLLSTÄNDIG EINGEARBEITET (Stand 06.07.2026):** Alle Punkte dieser Datei sind in den Entwicklungsplänen V4.0–V6.0 umgesetzt. Einzige Ausnahmen: 2FA (= AP-16) und blockweise Rechtevergabe (= AP-15) — beide als nachgelagerte Pakete im Plan V6.0 (§3) geführt. Diese Datei dient nur noch als Archiv.
|
||||
|
||||
---
|
||||
|
||||
Könntest Du das Feld so anlegen, dass der so eine URL mit Parametern annimmt? Dann könnten man gleich in den Konfigurator springen bei solchen Anbietern (Versandverpackungen):
|
||||
solceh URLS https://www.kartonsaufmass.de/bestellen?bom_configuration=%7B%2522length%2522:125,%2522width%2522:125,%2522height%2522:30,%2522amount%2522:100%7D
|
||||
|
||||
Wird entsprechend validiert und mit einem Fehler ausgegeben
|
||||
|
||||
Lege ich einen neuen Lieferanten an, dann sagt er URL eingeben, obwohl eine drinsteht. Wenn ich die rausmache, dann geht das Abspeichern. Also genau umgekeht wie es eigentlich soll.
|
||||
|
||||
danke. Könntest Du bei „Neue Produktion“ bitte die Incis aus der Herstellerrezeptur nehmen?
|
||||
|
||||
Dort auch die Wörter / Zeile mit **Charge** und **Menge (g)** bei dem jeweiligen INCI aus den Tabellen nehmen. Das ist zu viel fürs Auge. Bei Menge steht im Feld als Platzhalter dann 0 g, dann weiß man, dass man Gramm eintragen muss.
|
||||
|
||||
|
||||
|
||||
Wenn ich „Weitere Charge“ anklicke, reicht es, wenn ein weiteres Dropdown aufgeht.
|
||||
|
||||
|
||||
**
|
||||
Neuer Einkauf**
|
||||
|
||||
A) Felder für Preise wie folgt:
|
||||
|
||||
- Dropdown UST (Auswahl 19%, 7% etc.) -> Muss ich vorab in den Einstellungen definieren können
|
||||
|
||||
- Brutto-Preis pro kg
|
||||
|
||||
- Netto-Preis pro kg
|
||||
|
||||
-> Manche Shops zeigen mir den Netto-Preis an, manche den Brutto-Preis. Ich will da nicht immer rumrechnen. Ich trage entweder den Netto- oder Bruttobetrag ein und das jeweilige leere Feld berechnet sich dann von selbst.
|
||||
|
||||
|
||||
|
||||
B) Bitte einen ausgefüllten Einkauf duplizierbar machen. Hintergrund: Manchmal kommen Rohstoffe in 2,3 Kanistern mit unterschiedlichen Chargen, dann muss ich das nicht alles nochmal ausfüllen.
|
||||
|
||||
|
||||
|
||||
c) Bitte die Icons Auge, Stift und Mülleimber in der Übersicht „Einkauf & Wareneingang“ weiter auseinander und ein Stück größer - ist schwer anzuklicken auf dem ipad - bitte bei allen Tabellen in den Menüpunkten
|
||||
|
||||
|
||||
|
||||
…………….
|
||||
|
||||
|
||||
|
||||
**Lieferanten**
|
||||
|
||||
A) Hier muss ich ein Kästchen anklicken können, ob ich per Mail oder online in einem Shop bestelle. Hintergrund: Bei manchen Lieferanten muss ich per Mail bestellen, da soll dann in der Liste für den Rohstoffbestand ein Link entweder zu einem Onlineshop oder ins Mailformular mit der richtigen Email-Adresse bereits hinterlegt erscheinen.
|
||||
|
||||
|
||||
|
||||
B) Ich möchte bei jedem Lieferanten eine Lieferzeit eintragen können, die ich vorher definiere (z. B. 3-5 Werktage). Aber bitte als Textfeld. Zuätzlich benötige ich bei den INCIs auch ein Feld, wo ich eine Lieferzeit eintragen kann (auch als Textfeld). Wenn da was drinsteht, dann überschreibt der Inhalt den vom Feld beim Lieferanten. Hintergrund: Dragonspice z.B. liefert immer prompt nach 3 Tagen. Manche (wenn auch wenige) INCI von denen sind aber nicht immer vorrätig oder müssen vorbestellt werden.
|
||||
|
||||
|
||||
|
||||
…………….
|
||||
|
||||
|
||||
|
||||
**INCIs**
|
||||
|
||||
A) Bei jedem INCI muss ich eine Mehrfachauswahl als Dropdown haben, bei welchen Lieferanten ich dieses eine INCI kaufen kann (beziehe nicht immer beim gleichen). Das brauchen wir dann später in der Übersicht Rohstoffbestand.
|
||||
|
||||
|
||||
|
||||
B) Pro INIC möchte die Höhe der UST hinterlegen über ein Dropdown (7%, 19% etc. -> anzulegen in Einstellungen).
|
||||
|
||||
|
||||
|
||||
…………….
|
||||
|
||||
|
||||
|
||||
**Neue Produktion**
|
||||
|
||||
A) Bitte weniger Linien - Überschriften Charge und Menge bei den einzelnen Rohstoffen weg - steht ja im Dropdown / Feld (hier noch g hinter die Zahl)
|
||||
|
||||
|
||||
|
||||
B) Im Dropdown für die Charge steht zusätzlich noch der Lieferant, also „**Manske GmbH - DE-170722 - 30.09.2028**“ (Datum bitte so in dieser Schreibweise und die Buchstaben MHD raus). Die Charge darf auch nur angezeigt werden, wenn noch was von ihr da ist.
|
||||
|
||||
|
||||
|
||||
C) Das mit den Megenangaben bei einer neuen Produktion müssen wir eleganter lösen. Sonst muss ich ja ständig in die Excel schauen und manuell übertragen. Vorschlag: Ich trage oben die Stückzahl ein (z.B. 50), unten errechnet sich in den Felden „Menge Soll (g)“ die vollständige Zahl, die ich brauche - **auf Basis der Herstellerrezeptur!.** Daneben steht ein weiteres Feld „Menge Ist (g)“. Wenn ich Sonnenblumenöl Kanister Charge A dann 2000 von benötigten 5000 g leere, trage ich ins Ist-Feld 2.000 g ein für Charge A und mache dann eine weitere Charge (zweite Zeile) auf, wo ich ins Ist-Feld dann 3000 g eintrage. Habe ich ausreichend von einer Charge, also sind da die vollständigen 5.000 g im Kanister, trage ich im Ist-Feld nichts ein, da reicht ja dann die Zahl im Soll-Feld. Bei Speichern übernimmt der dann die Felder, die ausgefüllt sind. Mann kann **nicht** in beide Felder Zahlen schreiben!
|
||||
|
||||
|
||||
|
||||
D) Schau Dir mal bitte „Neue Produktion“ auf dem ipad an. Die Felder Produktionsdatum und Produzierte Stückzahl überlappen grafisch.
|
||||
|
||||
|
||||
|
||||
E) Wir haben die Produktentwicklung noch nicht bedacht, da gehen ja auch Rohstoffe für drauf. Unter dem Menüpunkt „Produktion“ brauchen wir noch einen Menüpunkt Produktentwicklung. Konzept dafür folgt, aber bitte schon mal einfügen, damit wir das nicht vergessen.
|
||||
|
||||
|
||||
|
||||
…………….
|
||||
|
||||
|
||||
|
||||
**Übersicht Rohstoffeinkauf**
|
||||
|
||||
Neuer Menüpunkt: Rohstoffbestand
|
||||
|
||||
|
||||
|
||||
Das ist unsere Übersicht, in der ich sehen kann, welche Rohstoffe im Lager sind. Alles weitere in den Screens anbei.
|
||||
|
||||
|
||||
|
||||
…………….
|
||||
|
||||
|
||||
|
||||
**Produktbestand**
|
||||
|
||||
A) Wir haben einen Hauptmenüpunkt: Produktbestand (sh. Screen anbei - hier trage ich Ein und Ausgänge ein - ganz simpel)
|
||||
|
||||
Darunter einen weiteren Menüpunkt: Historie (Hier machen wir ein umfangreiches Archiv vor allem fürs Finanzamt, bei dem man jedes einzelne Produkt nachverfolgen kann, wenn nötig. D.h., JEDER Ein- und Ausgang wird hier dokumentiert - sei es durch einen Verkauf über die Shops oder die manuelle Eingabe z. B. durch Verschenken von Testern. Hier gibt es zwei Screens für.
|
||||
|
||||
|
||||
|
||||
B) Bei dem Produktbestand dürfen nur Hauptprodukte angezeigt werden. Also die „Bio Tattoocreme 15 ml (einzeln)“ ist das Hauptprodukt, das Produkt Bio Tattoocreme 50 Stück als Set ist das „Child-Produkt“ davon. Das muss ich also in den Produkten noch vermerken. Musst Du Dir was überlegen. Aber beim Child-Produkt könnte man das unten im Bereich Verpackung & Material noch mit angeben, dass wir hier 50 x das Hauptprodukt haben.
|
||||
|
||||
|
||||
|
||||
…………….
|
||||
|
||||
|
||||
|
||||
**2FA - Google Authenticator für die Admins**
|
||||
|
||||
Wie besprochen
|
||||
|
||||
|
||||
|
||||
Rechtevergabe - Wir vergeben pro Block ein Zugriffsrecht. Am Ende sind Mitarbeiter Admins, aber ich kann als SuperAdmin anklicken, welchen Block die sehen und bearbeiten können. Also ein Mitarbeitern kann z. B. die Produktliste einsehen, aber nicht bearbeiten oder einsehen UND bearbeiten.
|
||||
|
||||
|
||||
|
||||
………………
|
||||
|
||||
|
||||
|
||||
**Nicht vorrätig**
|
||||
|
||||
Brauche die Funktion „Nicht vorrätig“ inkl. Zeitangabe. Ich hake also ein Kästchen im Produkt an „Nicht vorrätig“ und trage dahinter eine Zahl in einem Feld ein (Anzahl Tage). Von da an zählt das System runter und die Zahl aktualisiert sich dann in der Bestellansicht. Ein zweites Kästchen mit „Auf unbestimmte Zeit vergriffen“ - da dann natürlich kein Feld für Tage.
|
||||
|
|
@ -1,115 +0,0 @@
|
|||
> **✅ VOLLSTÄNDIG UMGESETZT (Stand 06.07.2026):** Alle Anforderungen dieser Runde sind als AP-20 (Rohstoffbestand-Filter), AP-21 (INCI-Ebene), AP-22 (Produktbestand), AP-23 (Rezeptur-Phasen), AP-24 (Chargen-Präfix), AP-25 (Lieferbestand), AP-26 (Ausschuss-Gründe), AP-27 (Wareneingang Chargen-Merge) und AP-28 (neue Produktions-Maske + Produktionsergebnis) umgesetzt — Details im Umsetzungsprotokoll von `dev/product management /entwicklungsplan-aktualisiert-06-07-2026.md` (§6). Diese Datei dient nur noch als Archiv.
|
||||
|
||||
---
|
||||
|
||||
Datum 12-06-2026
|
||||
|
||||
|
||||
**Rohstoffbestand:**
|
||||
|
||||
1. Es ist gut, alle Rohstoffe aufzunehmen und einen Überblick zu haben, was alles im Haus ist. Aber in der Ansicht Rohstobestand muss ich die Filtermöglichkeit haben:
|
||||
|
||||
a) Alle Rohstoffe anzeigen (also auch solche, die nicht in aktiven Produkten drin sind, die ich aber z. B. für Neuentwicklung eingekauft habe)
|
||||
|
||||
b) Nur Rohstoffe aus Herstellerrezepturen
|
||||
|
||||
|
||||
Allergene etc. dürfen da gar nicht auftauchen. Hier müsste ich bei den INCI also die Möglichkeit eines Kontrollkästchens haben „Kein Rohstoffbestand“.
|
||||
|
||||
|
||||
|
||||
…
|
||||
|
||||
|
||||
|
||||
**INCI-Ebene:**
|
||||
|
||||
1. Wenn ich bei Rohstoffbestand auf einen Rostoff klicke (nimm mal ZinClearXP), dann sehe ich ganz rechts „per Mail“. Aber wo definiere ich das? Da ich bei Dragonspice sowohl im Onlineshop als auch per Mail bestellen muss (z.B. größere Mengen), dann muss ich also im INCI selbst eintragen, ob online oder per Mail. Daher muss ich auf INCI-Ebene einstellen können a) Lieferant und dahinter b) URL (bleibt die URL frei, muss ich per Mail bestellen). Dann ein Plus für „Weiteren Lieferanten anlegen“.
|
||||
|
||||
|
||||
|
||||
2. Ich möchte die INCI-Liste filtern können. Also oben ein Kästchen „nur aktive“ anklicken. „Aktive“ = Alle INCI aus Herstellerrezepturen (mindestens 1 Produkt aktiv).
|
||||
|
||||
|
||||
|
||||
3. Bitte bei INCI noch ein Feld rein, wo ich einen Alternativen Namen eintragen kann, damit ein Mitarbeiter das INCI auch findet (Beispiel: In der Herstellerrezeptur steht LECITHIN, der Handelsname auf der Packung lautet aber Phospholipon 80 H).
|
||||
|
||||
|
||||
|
||||
4. Außerdem ein Feld, wo ich eintragen kann, wo das INCI / die Verpackung etc. liegt. Aktuell plane ich die Phrase RAUM | REGAL-NR. | BUCHSTABE (Raum 1 | Regal 3 | A). Am besten ich lege diese Felder auch unter Einstellungen zentral an, falls ich da mal was ändern muss, kann ich das gleich übergeordnet für alle machen.
|
||||
|
||||
|
||||
|
||||
…
|
||||
|
||||
|
||||
|
||||
**Produktbestand:**
|
||||
|
||||
1. Ich möchte sortieren können in der Tabelle nach Dringlichkeit. Also Klick auf Status und dann von oben nach unten erscheinen die dringlichsten. Kann defaultmäßig auch schon so eingestellt sein (falls es nicht schon so ist). Die Filter oben sind gut, aber „Produkte“ und „Bestand ok“ kann man nicht anklicken.
|
||||
|
||||
|
||||
|
||||
2. Auf Produktebene muss ich anklicken können, ob das Produkt im Produktbestand erscheinen soll oder nicht (z.B. Abrechnung Druckkosten für Logo-Etiketten haben da nix zu suchen).
|
||||
|
||||
|
||||
|
||||
3. Bitte hier noch Spalte „Verbrauch pro Monat“ reinbauen (Durchschnitt der letzten 6 Monate).
|
||||
|
||||
|
||||
|
||||
…
|
||||
|
||||
|
||||
|
||||
**Produktebene:**
|
||||
|
||||
1. Auf Produktebene müssen unter der Herstellerrezeptur noch die Phasen angelegt werden können. (siehe Screen dev/product management /screens/2026-12-06-Rezeptur-phase.jpeg).
|
||||
|
||||
|
||||
|
||||
2. Ich brauche noch ein Feld für ein Präfix für die Chargen-Nr. der Produkte. Es setzt sich zusammen aus einem Kürzel für die Kategorie (TP - Tattoopflege) + Produkt-Nr. (1) + Produktionsdatum. Beispiel Tattoocreme: TP1150626. Diese Chargen-Nr. schreiben wir immer in eins durch. Ich lege also das Präfix „TP1“ auf Produktebene an. In der Maske für die neue Produktion erstellt sich dann in dem Textfeld also die Chargen-Nr. von selbst, aber editierbar, da wir oft alte Chargen-Nr. Etiketten verwenden.
|
||||
|
||||
|
||||
|
||||
…
|
||||
|
||||
|
||||
|
||||
**Lieferbestand:**
|
||||
|
||||
Bei der Funktion „erst in 12 Tagen wieder lieferbar“ - hier machen wir das Produkt doch wieder kaufbar. Soll der VP selber entscheiden, ob er die Ware später bekommt. Ich würde hier außerdem präferieren, dass ich auf Produktebene eine Datum einstelle und für den VP dann die Anzahl der Tage erscheint, die sich dann täglich natürlich aktualisieren.
|
||||
|
||||
|
||||
|
||||
….
|
||||
|
||||
|
||||
|
||||
**Ausschuss:**
|
||||
|
||||
Ich möchte die Gründe für den Ausschluss unter Einstellungen selber anlegen können.
|
||||
|
||||
|
||||
|
||||
….
|
||||
|
||||
|
||||
|
||||
**Wareneingang:**
|
||||
|
||||
Ich bestelle heute Sonnenblumenöl mit Charge XY-123. In 3 Wochen kommt wieder Sonnenblumenöl mit der gleichen Chargen-Nr. XY-123. Hier brauche ich eine Lösung, dass sich das bei weiteren Einkauf dazuaddiert. Man müsste in der Maske also erstmal schauen, ob die Charge schon im Hause ist. Wir erweitern aber nicht einfach die Charge - den Einkaufsvorgang erfassen wir trotzdem.
|
||||
|
||||
|
||||
|
||||
….
|
||||
|
||||
|
||||
|
||||
**Produktion:**
|
||||
|
||||
Ich habe eine neue Maske konzipiert für die Produktion (siehe Screen dev/product management /screens/2026-12-06-neue-produktion.jpeg). Da fließen natürlich auch die neuen Rezeptur-Phasen mit ein. Wichtig: Der Produktbestand (!) errechnet sich nicht aus der oben definierten Auswahl Produkt und Anzahl. Das ist nur zur Planung. Ganz unten trägt man hinterher ein, was genau draus entstanden ist. Beispiel: Ich plane 50 x 50 ml HAELD Deobalm. Aus dieser Masse entstehen dann 40 x 50 ml und 50 x 5 ml. Das muss ich also extra eintragen.
|
||||
|
||||
|
||||
|
||||
Der Rohstoffbestand berechnet sich dann wie gehabt aus den Werten, die ich hinter jeder Charge eintrage.
|
||||
|
|
@ -1,142 +0,0 @@
|
|||
# Testleitfaden Warenwirtschaft — Anforderungsrunde 12.06.2026
|
||||
|
||||
> **Archiv (Version 1).** Der aktuelle Leitfaden (Version 3, Stand 09.09.2026) liegt in `resources/docs/testleitfaden.md` und ist in der App unter **Einstellungen → Leitfaden** erreichbar.
|
||||
|
||||
> **Stand:** 06.07.2026 · Alle Punkte aus `nächsten Anforderungen an die WaWi.md` (12.06.2026) sind umgesetzt.
|
||||
> Dieser Leitfaden führt einmal durch alle neuen Funktionen — in der Reihenfolge eines typischen Arbeitsablaufs, sodass jede Stelle direkt im Browser nachgeschaut und getestet werden kann.
|
||||
> Die fachlichen Erklärungen dazu stehen wie gewohnt in der App unter den **[Hinweisen zur Warenwirtschaft](/admin/inventory/notices)**.
|
||||
|
||||
---
|
||||
|
||||
## 1. Einstellungen: Lagerort-Bausteine & Ausschuss-Gründe
|
||||
|
||||
**Wo:** Menü **[Einstellungen → Allgemein](/admin/inventory/general)**
|
||||
|
||||
**Neu:**
|
||||
- Drei neue Karten **Räume**, **Regale**, **Fächer** — die zentralen Bausteine für Lagerorte nach dem Schema *Raum 1 | Regal 3 | A*.
|
||||
- Karte **Ausschuss-Gründe** (aus Runde 12.06.): Gründe für Ausgang/Ausschuss selbst anlegen, umbenennen, deaktivieren.
|
||||
|
||||
**So testen:**
|
||||
1. Je einen Raum (z. B. „Raum 1"), ein Regal („Regal 3") und ein Fach („A") anlegen.
|
||||
2. Einen Eintrag umbenennen → die Änderung wirkt übergeordnet überall, wo der Baustein verwendet wird.
|
||||
3. Einen Ausschuss-Grund anlegen (z. B. „Verkleckert") — der taucht später in Schritt 8 auf.
|
||||
|
||||
---
|
||||
|
||||
## 2. INCI-Ebene: Lieferanten mit Bestellweg, Alternativname, Lagerort
|
||||
|
||||
**Wo:** Menü **[Produkte → Inhaltsstoffe](/admin/product/ingredients)**, einen INCI öffnen (z. B. ZinClear XP)
|
||||
|
||||
**Neu:**
|
||||
- **Lieferanten-Zeilen mit „+ weiteren Lieferanten anlegen":** je Zeile Lieferant + **URL**. URL eingetragen ⇒ Bestellung im Online-Shop; URL leer ⇒ Bestellung per Mail.
|
||||
- Feld **Alternativer Name** (Handelsname, z. B. LECITHIN → *Phospholipon 80 H*).
|
||||
- Drei Dropdowns **Raum / Regal / Fach** (die Bausteine aus Schritt 1).
|
||||
- Checkbox **„Kein Rohstoffbestand"** (für Allergene u. Ä. — wirkt in Schritt 3).
|
||||
|
||||
**So testen:**
|
||||
1. Beim INCI zwei Lieferanten anlegen: einen **mit** URL (z. B. Dragonspice-Shoplink), einen **ohne**.
|
||||
2. Alternativnamen und Lagerort (Raum 1 | Regal 3 | A) setzen, speichern.
|
||||
3. **Filter „nur aktive"** oben in der INCI-Liste anhaken → es bleiben nur INCI übrig, die in der Herstellerrezeptur mindestens eines aktiven Produkts vorkommen.
|
||||
|
||||
**Ergebnis prüfen:** In der Rohstoffbestand-Detailansicht (Schritt 3) erscheint je Lieferant der Button **„Zum Shop"** bzw. **„Per Mail"**; Alternativname und Lagerort werden im Kopf angezeigt.
|
||||
|
||||
---
|
||||
|
||||
## 3. Rohstoffbestand: Filter & Ausblendungen
|
||||
|
||||
**Wo:** Menü **[Rohstoffbestand](/admin/inventory/raw-material-stock)**
|
||||
|
||||
**Neu:**
|
||||
- Umschalter **„Alle" / „Nur aus Herstellerrezepturen"** oben in der Übersicht.
|
||||
- INCI mit Häkchen **„Kein Rohstoffbestand"** erscheinen gar nicht (auch nicht im roten Kritisch-Zähler).
|
||||
|
||||
**So testen:**
|
||||
1. Auf „Nur aus Herstellerrezepturen" klicken → Rohstoffe, die nur für Neuentwicklungen eingekauft wurden, verschwinden; auf „Alle" sind sie wieder da.
|
||||
2. Bei einem Test-INCI „Kein Rohstoffbestand" anhaken → er verschwindet in beiden Modi.
|
||||
|
||||
---
|
||||
|
||||
## 4. Produktebene: Rezeptur-Phasen & Chargen-Präfix
|
||||
|
||||
**Wo:** Menü **[Produkte → Übersicht](/admin/product/show)**, ein Produkt bearbeiten (z. B. Tattoocreme)
|
||||
|
||||
**Neu:**
|
||||
- **Hersteller-Rezeptur in Phasen** (Phase A, B, …): je Phase eigene Rohstoffe, ein **Notizfeld** (z. B. „auf 70 °C erhitzen"), Umbenennen möglich; Rohstoffe lassen sich per Drag & Drop **innerhalb und zwischen Phasen** verschieben. Die 100-%-Summe gilt weiterhin **über alle Phasen zusammen**.
|
||||
- Feld **„Chargen-Nr.-Präfix"** in der Warenwirtschaft-Karte (z. B. `TP1` = Tattoopflege + Produkt-Nr. 1).
|
||||
- **Lieferbestand** (aus Runde 12.06.): Feld „Wieder lieferbar ab" als **Datum**; das Produkt bleibt kaufbar, im Shop erscheint die tagesaktuell berechnete Anzahl Tage.
|
||||
|
||||
**So testen:**
|
||||
1. In der Hersteller-Rezeptur „+ Neue Phase" klicken, Rohstoffe zuordnen, eine Notiz eintragen, einen Rohstoff in eine andere Phase ziehen → Summe unten muss weiter 100 % ergeben.
|
||||
2. Präfix `TP1` eintragen und speichern → wirkt in Schritt 7 (Produktion).
|
||||
3. „Wieder lieferbar ab" auf ein Datum in 12 Tagen setzen → Produkt im Shop ansehen: kaufbar, mit Tage-Hinweis.
|
||||
4. Produkt **kopieren** → Phasenstruktur wird mitkopiert.
|
||||
|
||||
---
|
||||
|
||||
## 5. Einkauf & Wareneingang: gleiche Charge zusammenführen
|
||||
|
||||
**Wo:** Menü **[Einkauf & Wareneingang](/admin/inventory/stock-entries)**
|
||||
|
||||
**Neu:**
|
||||
- Beim **Buchen des Wareneingangs** (Stufe 2) prüft die Maske beim Eintippen der Chargennummer automatisch, ob diese Charge für den Rohstoff **schon im Haus** ist: Hinweis „Charge bereits im Haus" mit Restbestand, Lagerort und MHD — **MHD und Qualität werden vorbelegt** (bleiben überschreibbar).
|
||||
- Der Einkaufsvorgang bleibt trotzdem **separat erfasst** (eigener Eintrag mit Preis und Datum).
|
||||
|
||||
**So testen:**
|
||||
1. Sonnenblumenöl bestellen und mit Charge `XY-123` als eingegangen buchen.
|
||||
2. Sonnenblumenöl **erneut** bestellen und beim Buchen wieder `XY-123` eintippen → der blaue Hinweis erscheint, MHD ist vorbelegt.
|
||||
3. Danach Schritt 6 ansehen: die Charge erscheint dort **einmal mit summiertem Rest**.
|
||||
|
||||
---
|
||||
|
||||
## 6. Rohstoffbestand-Detail: Chargen summiert
|
||||
|
||||
**Wo:** Menü **[Rohstoffbestand](/admin/inventory/raw-material-stock)**, den Rohstoff aus Schritt 5 anklicken
|
||||
|
||||
**Neu:** Tabelle **„Verfügbare Chargen"** zeigt je Chargennummer **eine Zeile mit Summen-Rest** und dem Vermerk „2 Einkäufe"; darunter die einzelnen Einkäufe als eingerückte Unterzeilen („Einkauf vom …"). Außerdem: Spalte **„Letzter Einkauf (Netto/kg)"** je Lieferant und die Bestell-Buttons aus Schritt 2.
|
||||
|
||||
**So testen:** Restbestand der Charge = Summe beider Einkäufe; beide Einkaufszeilen mit eigenem Datum sichtbar.
|
||||
|
||||
---
|
||||
|
||||
## 7. Produktion: neue Maske mit Produktionsergebnis
|
||||
|
||||
**Wo:** Menü **Produktion → Produktionen → [Neue Produktion](/admin/inventory/productions/create)**
|
||||
|
||||
**Neu (Kernstück der Runde):**
|
||||
- Oben nur noch **Planung**: „Geplante Stückzahl (Planung)" — **bucht keinen Bestand**.
|
||||
- **INCI-Liste** der Herstellerrezeptur: Name, **Alternativer Name**, Qualität, Anteil %, Gramm gesamt, **Regal** — mit Summenzeile.
|
||||
- **Chargen-Zuordnung nach Phasen** gegliedert (inkl. Phasen-Notiz) mit **Status-Ampel** je Rohstoff (grün = eingetragene Menge entspricht dem Soll).
|
||||
- Das **Chargen-Dropdown** zeigt zusammengeführte Chargen mit Summen-Rest (z. B. „… — Rest 8.000 g (2 Einkäufe)"); der Verbrauch wird automatisch nach frühestem MHD auf die Einkäufe verteilt.
|
||||
- Ganz unten **„Produktionsergebnis"**: Zeilen mit Produkt + produzierte Stückzahl + **Chargen-Nr.** (vorbelegt aus Präfix + Produktionsdatum, z. B. `TP1150626` — editierbar), „+ weitere Ergebniszeile" für **mehrere Output-Produkte**.
|
||||
|
||||
**So testen (Beispiel aus der Anforderung):**
|
||||
1. 50 × „50 ml Deobalm" **planen**, Chargen zuordnen (Ampeln grün).
|
||||
2. Im Produktionsergebnis eintragen: **40 × 50 ml** und (zweite Zeile) **50 × 5 ml** — Chargen-Nr. wird je Zeile automatisch vorgeschlagen.
|
||||
3. Speichern → Detailseite zeigt die Karte „Produktionsergebnis".
|
||||
4. **Produktbestand prüfen** (Schritt 8): 50-ml-Produkt +40, 5-ml-Produkt +50 — **nicht** +50 aus der Planung.
|
||||
5. Produktion **bearbeiten**, Ergebnis ändern → der Produktbestand korrigiert sich als Differenz-Gegenbuchung (Historie bleibt vollständig).
|
||||
6. Rohstoffbestand (Schritt 6) prüfen: abgezogen wurden die **je Charge eingetragenen Gramm** — unabhängig vom Ergebnis.
|
||||
|
||||
---
|
||||
|
||||
## 8. Produktbestand & Ausschuss (aus Runde 12.06., bereits länger live)
|
||||
|
||||
**Wo:** Menü **[Produktbestand → Übersicht](/admin/inventory/product-stock)** und **[Ausgang / Ausschuss](/admin/inventory/stock-disposals)** (Historie: **[Produktbestand → Historie](/admin/inventory/product-stock/history)**)
|
||||
|
||||
**Neu seit 12.06.:**
|
||||
- Übersicht **standardmäßig nach Dringlichkeit sortiert**; alle **vier Status-Kacheln** oben sind klickbare Filter.
|
||||
- Spalte **„Verbrauch pro Monat"** (Durchschnitt der letzten 6 Monate).
|
||||
- Auf Produktebene Häkchen **„Im Produktbestand anzeigen"** — z. B. Logo-Etiketten-Abrechnungen ausblendbar.
|
||||
- Ausschuss-Erfassung nutzt die **selbst gepflegten Gründe** aus Schritt 1; Chargen-Auswahl setzt den Lagerort automatisch.
|
||||
|
||||
**So testen:** Kacheln durchklicken, ein Produkt per Häkchen ausblenden, einen Ausschuss mit eigenem Grund buchen und in der Historie wiederfinden.
|
||||
|
||||
---
|
||||
|
||||
## Hinweis am Rande
|
||||
|
||||
Die Listen **Einkauf & Wareneingang** und **Produktionen** zeigen aus Performance-Gründen die neuesten 500 Einträge; darüber erscheint ein Link **„Alle anzeigen"**. Offene Bestellungen sind immer vollständig gelistet.
|
||||
|
||||
## Was bewusst noch nicht dabei ist (nachgelagert)
|
||||
|
||||
Audit-Trail, 2FA, blockbasierte Rechte und die WaWi-Einstellungsseite folgen in der nächsten Runde — hier fließen zuvor noch weitere Anforderungen ein (siehe Entwicklungsplan V6.0, §3). *(Der Shop-Bestandsabzug beim Versand inkl. Sets ist inzwischen umgesetzt — AP-13; Versand über das Board nur mit Zahlungsfreigabe, Rechnung/API ausgenommen.)*
|
||||
Loading…
Add table
Add a link
Reference in a new issue