From d93c676b6bc401a280eb6004e1ee7923aaffde35 Mon Sep 17 00:00:00 2001 From: Kevin Adametz Date: Wed, 26 Aug 2026 11:03:28 +0000 Subject: [PATCH] Warenwirtschaft: Entwicklungsplan V7.0 (Testphasen-Feedback 26.08.) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Kundenfeedback aus der Testphase am Code + Live-DB verifiziert und in einen Umsetzungsplan überführt (AP-34…AP-51, ~15–26 PT): 9 bestätigte Bugs (u. a. Varianten-Artikelnummer, Produktionsmengen 100 g statt Füllmenge, leere Rezepturphasen, „Enthalten in"-Doppelung) plus Erweiterungen. WooCommerce-Ampel ist voraussichtlich shopseitig (Status-Cron/Auth), kein ERP-Fehler. Sechs Klärungspunkte (D-1…D-6) offen. Noch nichts umgesetzt. Rohfeedback des Kunden liegt als entwicklungsplan-aktualisiert-2026-08-26.md bei. Co-Authored-By: Claude Opus 4.8 (1M context) --- .../entwicklungsplan-V7-2026-08-26.md | 149 ++++++++++++++++++ ...ntwicklungsplan-aktualisiert-2026-08-26.md | 72 +++++++++ dev/product management /README.md | 11 ++ 3 files changed, 232 insertions(+) create mode 100644 dev/product management /01-entwicklungsplaene/entwicklungsplan-V7-2026-08-26.md create mode 100644 dev/product management /01-entwicklungsplaene/entwicklungsplan-aktualisiert-2026-08-26.md diff --git a/dev/product management /01-entwicklungsplaene/entwicklungsplan-V7-2026-08-26.md b/dev/product management /01-entwicklungsplaene/entwicklungsplan-V7-2026-08-26.md new file mode 100644 index 0000000..b24f84b --- /dev/null +++ b/dev/product management /01-entwicklungsplaene/entwicklungsplan-V7-2026-08-26.md @@ -0,0 +1,149 @@ +# Entwicklungsplan V7.0 — Testphasen-Feedback 26.08.2026 + +> **Stand:** 26.08.2026 · **Basis:** Kundenfeedback aus der Testphase +> ([entwicklungsplan-aktualisiert-2026-08-26.md](entwicklungsplan-aktualisiert-2026-08-26.md)) +> **Vorgänger:** V6.0 ([entwicklungsplan-aktualisiert-06-07-2026.md](entwicklungsplan-aktualisiert-06-07-2026.md)) +> **Verifikation:** Jeder Befund wurde am Code **und** an der eingespielten Live-DB geprüft (Dev-Container). Die Datei-/Zeilenangaben sind der aktuelle Stand. +> **Status:** Planungsdokument — **noch nichts umgesetzt.** Umsetzung erst nach Freigabe & Klärung (Abschnitt D). + +Die mit **`#`** markierten Punkte hat der Kunde als **buggy/dringend** priorisiert. Aufwände in Personentagen (PT), inkl. Test. + +--- + +## Kurzfazit der Prüfung + +- **9 der Punkte sind bestätigte Bugs**, mit klarer Ursache im Code. Der wichtigste (Varianten-Artikelnummer) liegt **zur Hälfte im WooCommerce-Connector**, muss also auch shopseitig ausgerollt werden. +- **Die WooCommerce-Ampel ist vermutlich KEIN Partnercenter-Fehler** — das System liefert für versendete Bestellungen bereits „grün-fähige" Status. Ursache ist mit hoher Wahrscheinlichkeit der Status-Abgleich-Cron/Auth im Shop (Abschnitt A, AP-38). Bitte zuerst dort prüfen. +- Der Rest sind **Funktionserweiterungen** unterschiedlicher Größe. Einige hängen an **Kundenentscheidungen** (Abschnitt D) und sollten nicht vorher gebaut werden. +- **Grobschätzung Gesamt: ca. 15–26 PT.** Die dringenden Bugs (Abschnitt A) machen davon ca. 8–14 PT aus. + +--- + +## A. Kritische Bugs (dringend) + +### AP-34 `#` — Artikelnummer-Zuordnung für Varianten +**Befund (bestätigt):** Bestellungen mit Produktvarianten (z. B. „Häld Deo Creme ohne Natron") werden im Versand nicht automatisch zugeordnet — aktuell manuell nachgepflegt. +**Ursache (zwei zusammenwirkende Fehler):** +1. **Connector schickt die falsche SKU.** In `dev/partnercenter-api/public/partnercenter-api/partnercenter-api-requests/order.php` liest `compose_cart_content()` mit `get_product_id()` (Zeile ~241) das **Elternprodukt** der Variation und sendet dessen `get_sku()` (Zeile ~257). Die **eigene Artikel-Nr. der Variation** (das „eigene Feld", das der Kunde meint) liegt am Variations-Objekt (`get_variation_id()` / `$order_item->get_product()`) und wird nie gelesen. +2. **Importer zerschneidet die SKU.** `ShoppingUserController::prepareOrder()` ([:728](../../../app/Http/Controllers/Api/ShoppingUserController.php)) nimmt nur den Teil **vor dem ersten „-"** (`explode('-', …)[0]`) und matcht gegen `wp_number`. Das unterstellt „eine Basis-Nr. + Suffix je Variante" — das Gegenteil der Realität: In der Live-DB ist **jede Variante eine eigene `products`-Zeile mit eigener `wp_number`** (z. B. Deocreme 50 ml = 100009, MINI 5 ml = 100029; kein `main_product_id` gesetzt). +**Lösung:** (a) Connector liest die **Variations-SKU** (Fallback auf Eltern-SKU nur wenn leer); (b) Importer matcht die **volle SKU** gegen `wp_number` (bzzgl. `number`), der „-"-Split wird nur noch optionaler Fallback. **Connector-Plugin muss neu in den Shop ausgerollt werden** (nächste Version). +**Aufwand:** 1,5–2,5 PT · **Klärung:** D-1 (Shop-SKU-Konvention). + +### AP-35 `#` — Produktionsmengen auf Füllmenge skalieren (statt 100 g) +**Befund (bestätigt):** Bei „HAELD Sanft 50 ml" werden die Rohstoffsummen auf **100 g** statt 50 g gerechnet. +**Ursache:** Die Rezeptur ist in **Prozent** hinterlegt (`product_ingredients.gram`, Spaltenkopf „Anteil %"); die Sollmenge = `gram(%) × factor × qty` **ohne** Multiplikation mit der Füllmenge des Produkts. `qty` ist die Stückzahl, keine Masse. Fundstellen: `ProductionService::buildRecipePayload` ([:562](../../../app/Services/ProductionService.php)), `ProductionService::requiredGramsByIngredient` ([:300](../../../app/Services/ProductionService.php)), JS-Spiegel `productions/_scripts.blade.php:119/138/189`. Live-DB: Produkt 134 hat `contents_total = 50`, Rezeptursumme = 100,0 %. +**Lösung:** Sollmenge = `(gram/100) × contents_total × factor × qty`, konsistent an allen drei Stellen + INCI-Spalten. Der Kunde erwartet für 50 ml = 50 g (⇒ Produktebene 1 g/ml angenommen; feinere Umrechnung siehe AP-42 nur für **Rohstoff**-Bestand). +**Aufwand:** 1–2 PT · **Klärung:** D-2 (Produkt-Nettomasse/1 g/ml-Annahme). + +### AP-36 `#` — Rezeptur-Textphasen ohne Rohstoffe anzeigen +**Befund (bestätigt):** Phasen ohne Rohstoffzeile (z. B. „Vorbereitung"/„Nachbereitung" mit reinem Hinweistext) erscheinen in der Produktion nicht. +**Ursache:** Datenmodell kann es (Spalte `recipe_phases.note`, Live-DB hat solche Phasen an Produkt 146), aber das JS verwirft leere Phasen: `productions/_scripts.blade.php:184` endet mit `.filter(g => g.ingredients.length > 0)`; die Phasenliste wird aus den Rohstoffzeilen abgeleitet statt aus `data.phases`. +**Lösung:** Phasenblöcke aus `data.phases` (Server-Reihenfolge `pos`) rendern, auch bei 0 Rohstoffen (Name + Notiz). Damit erscheint „Vorbereitung" automatisch über „Phase A". Deckt zugleich den Kundenwunsch nach Textfeldern über Phase A ab. +**Aufwand:** 0,5–1 PT. + +### AP-37 `#` — Rohstoffbestand „Enthalten in" listet Produkte doppelt +**Befund (bestätigt):** Bei „Brokkolisamenöl" (u. a.) erscheint jedes Produkt zweimal. +**Ursache:** `Ingredient::products()` ([:116](../../../app/Models/Ingredient.php)) ist ein `belongsToMany` über `product_ingredients` **ohne `distinct` und ohne `recipe_type`-Filter**. Jedes Produkt hat **zwei** Pivot-Zeilen (`recipe_type = manufacturer` + `product`) → Doppelung (Live-DB: 30 Zeilen für 15 Produkte). +**Lösung:** Produktliste deduplizieren (`distinct()` / Gruppierung nach `products.id`) bzw. auf einen `recipe_type` einschränken. Reine Anzeige-Korrektur, keine Pivot-Daten anfassen. +**Aufwand:** 0,25–0,5 PT. + +### AP-38 `#` — WooCommerce-Ampel bleibt orange +**Befund (bestätigt am Screenshot):** Abgeschlossene Bestellungen zeigen im Shop weiter Orange statt Grün. +**Prüfung:** Der Shop pollt `POST /api/wp/status` → `getAPIShippedType()`. In der Live-DB stehen versendete API-Bestellungen auf `shipped = 2` (111 Stück) bzw. `3`; der Endpoint liefert dafür `sent`/`close`, was der Connector (`admin/post-list.php`) auf **Grün** mappt. **Ein ERP-seitiger Fehler ließ sich nicht reproduzieren.** +**Wahrscheinliche Ursache (shopseitig):** Der Status wird im Shop mit `open` (orange) initialisiert und nur vom stündlichen Cron `partnercenter_api_fetch_orders_status` aktualisiert; feuert der Cron nicht oder scheitert die API-Auth (früher `return []` in `order-status.php`), bleibt alles auf Orange — unabhängig vom korrekten ERP-Wert. **Zuerst Shop-Cron & API-Zugangsdaten prüfen.** +**Latente ERP-Lücken (unabhängig, mitnehmen):** Status `5` (Wartestellung) fehlt in `$apiShippedTypes` → liefert `free` (gar kein Licht); `4` (Abholung/`pick_up`) und `10` (`cancel`) sind im Connector-Ampel-Switch nicht abgedeckt (⚠️). +**Lösung:** Shopseitige Diagnose (Cron/Auth) + ERP-Mapping für `5` ergänzen und Farbsemantik für `pick_up`/`cancel` festlegen. +**Aufwand:** 0,5–1 PT (ERP) + Shop-Diagnose · **Klärung:** D-3. + +### AP-39 `#` — Abwiege-Werte je Charge speicherbar + Ampel-Validierung (±5 %) +**Befund:** Die beim Abwiegen neben die Chargen eingetragenen Ist-Gramm sind nicht speicherbar; der reale Abzug soll aus diesen Werten kommen. +**Lösung:** Ist-Menge je Chargenzeile persistieren (Feld an `production_ingredients`), Bestandsabzug aus dem Ist-Wert. Ampel: **Orange** = nichts eingetragen; **Grün** = Wert vorhanden **und** max. ±5 % Abweichung vom Soll (Schutz vor Zahlendreher). Keine Gramm-Genauigkeit erzwingen. +**Aufwand:** 1,5–2,5 PT · **Bezug:** baut auf AP-35 (korrektes Soll). + +### AP-40 `#` — Produktionstabelle: Spalten „Bestand" + „Differenz", „Regal" → „Ablage" +**Befund/Lösung:** In der INCI-/Rohstofftabelle (`productions/_form_fields.blade.php:80`) rechts nach der Ablage zwei Spalten: **aktueller Bestand** des Rohstoffs und **Differenz** (Soll − Bestand, negativ = rot, positiv = grün). Bestand je Rohstoff liefert bereits `InventoryService::remainingByIngredient()` (nur noch in den Payload hängen). Spaltenkopf „Regal" → „Ablage". +**Aufwand:** 0,5–1 PT · **Bezug:** AP-35 (Soll für Differenz). + +### AP-41 `#` — Verpackungs-Vorschau nach oben + Phasen-Gramm-Summe +**Befund/Lösung:** (a) Box „Verpackung (Vorschau)" (`_form_fields.blade.php:96`) direkt unter die INCI-Tabelle verschieben (Blade-Umbau, JS-Selektor bleibt). (b) Je Phase Gesamtgramm in Klammern hinter dem Namen anzeigen („Phase A (345 g)"), Summe je Phasengruppe im Renderer (`_scripts.blade.php:261`). +**Aufwand:** 0,5–1 PT · **Bezug:** AP-35 (korrekte Gramm). + +### AP-42 `#` — Rohstoff-Dichte (g/ml) für realen Bestand +**Befund:** Rohstoffe werden in **Gramm** geführt; eine in ml eingekaufte Tinktur (z. B. Propolis 0,79 g/ml → 100 ml = 79 g) verfälscht sonst den Bestand. +**Lösung:** Nullable-Feld `ingredients.density` (g/ml). Ist es gesetzt und wird der Wareneingang in **ml** erfasst, wird bei der Buchung `ml × density` in Gramm umgerechnet und wie bisher als Gramm gespeichert (alle Aggregationen in `InventoryService` bleiben unverändert). Leeres Feld = Gewicht wie eingekauft (heutiges Verhalten). +**Aufwand:** 1,5–2,5 PT · **Klärung:** D-4 (ml-Erfassung im Wareneingang, Enum `unit`). + +--- + +## B. Produktion — weitere Funktionen + +### AP-43 — Zwischenspeichern (Entwurf) + „Produktion abschließen" +Speicher-Button in „Produktion abschließen" umbenennen (Pflichtfelder dort sinnvoll); zusätzlich 2–3 „Zwischenspeichern"-Buttons, die den Stand ohne Pflichtfeld-Validierung sichern (Entwurfsstatus an `productions`). +**Aufwand:** 1–2 PT. + +### AP-44 — Rezeptur-Darstellung aufhübschen +(a) Phasenkasten leicht (3–5 %) hinterlegen, inneren Kasten um die Chargen-Dropdowns entfernen; (b) Schriftgrößen vereinheitlichen + schwarz (wie INCI-Liste); (c) `#` iPad: Textfelder mit dem Finger vergrößerbar/bedienbar; (d) Phasenbeschreibung formatiert darstellen wie auf Produktebene eingegeben. +**Aufwand:** 1–2 PT · **Hinweis:** (c) iPad-Touch-Resize ggf. als eigenes UX-Detail. + +### AP-45 — Verpackungsverbrauch aus dem Produktionsergebnis +**Befund (bestätigt):** Verpackung (Etikett/Tiegel) wird derzeit aus der **Planmenge** gebucht (`ProductionService::syncPackagingSnapshot`, aus `productions.quantity`), nicht aus dem Ergebnis. Der Kunde will: Rohstoffe aus dem oberen Rezepturteil, **Verpackung nur aus dem Produktionsergebnis** (`production_outputs`). +**Lösung:** `syncPackagingSnapshot` auf die Output-Zeilen umstellen (je Ergebnisprodukt eigene Stückliste × Ergebnismenge), nach `persistOutputs` aufrufen. Vorschau-Box (AP-41) entsprechend an Outputs koppeln. +**Aufwand:** 1–1,5 PT. + +### AP-46 — INCI-Liste nach Konzentration sortiert (absteigend) +Aktuell nach `pos` sortiert (`Product::manufacturer_ingredients() ->orderByPivot('pos')`). Für die **INCI-Anzeige oben** nach `gram` absteigend sortieren (null zuletzt); die Phasen-/Chargenreihenfolge bleibt bei `pos`. +**Aufwand:** 0,25 PT. + +### AP-47 — „Produktionsrelevant"-Flag + Filter +**Befund:** Kein solches Feld vorhanden; das Produktions-Dropdown zeigt **alle** aktiven Einzelprodukte (`ProductionController::create/edit/copy`), nicht nur produktionsrelevante. +**Lösung:** Boolean `produktionsrelevant` an `products` + Schalter im Produktformular; Filter im Produktions-Dropdown und in der Rohstoffbestand-Box „Enthalten in" (blendet z. B. die Aloe-Produkte und die 5-ml-Variante aus, wenn nur die 50-ml-Basis produktionsrelevant ist). +**Aufwand:** 1–2 PT · **Bezug:** löst zugleich „Aloe ausblenden" (Rohstoffbestand) mit. + +--- + +## C. Stammdaten & Bestand + +### AP-48 — Produktbestand: Eingangs-/Ausgangsgründe editierbar +**Befund:** Buchungsgründe sind hartkodiert (`ProductStockController::manualReasons()`), gleiche Liste für Ein-/Ausgang. +**Lösung:** Eigene CRUD unter Einstellungen → Allgemeines nach Vorbild `DisposalReasonController`/`SettingCrudController` (Modell + Tabelle + FormRequest + Views), mit den 7 heutigen Werten geseedet; optional `direction`-Spalte, falls Ein-/Ausgang divergieren sollen. +**Aufwand:** 1–1,5 PT · **Klärung:** D-5 (getrennte Listen Ein/Aus?). + +### AP-49 — Inhaltsstoffe: Lieferanten-Dropdown nur Rohstoff-Lieferanten +**Befund:** `IngredientController` ([:49](../../../app/Http/Controllers/IngredientController.php)) lädt **alle** aktiven Lieferanten. Filtermechanik vorhanden: `Supplier::supplierCategories()` (Kategorie „Kosmetikrohstoffe", id 1). +**Lösung:** Query auf die Rohstoff-Kategorie einschränken (`whereHas('supplierCategories', …)`), möglichst über einen stabilen Marker (Slug/Flag an `SupplierCategory`) statt hartkodierter id. +**Aufwand:** 0,25–0,5 PT. + +### AP-50 — Lagerorte: „Waldbröl" löschbar + „Köln" als Default +**Befund:** Löschsperre greift, weil „Waldbröl" (id 2) von **3 `stock_entries`** referenziert wird (`DeletionGuard::locationBlockers`). Produktion hat Köln-Default bereits, **Wareneingang nicht**. +**Lösung:** (a) Löschen ermöglichen, ohne die Guard-Idee aufzugeben — Alt-Wareneingänge auf Köln umhängen **oder** Soft-Delete zulassen und inaktive Orte aus Auswahllisten ausblenden (`Location` nutzt SoftDeletes). (b) Köln als Default auch im Wareneingang (`StockEntryController` + `_form.blade.php:88`) und in weiteren Auswahlorten. +**Aufwand:** 0,5–1 PT · **Klärung:** D-6 (Alt-Einträge umhängen vs. Soft-Delete). + +### AP-51 — Lagerplatz-Felder für Produkte & Verpackung +**Befund:** Lagerort-Felder (Raum/Regal/Fach) gibt es bisher nur bei Rohstoffen. +**Lösung:** Gleiche Lagerplatz-Zuordnung für Produkte und Verpackungsartikel + Anzeige an den passenden Stellen (Produktbestand, Produktverpackung). Nutzt die bestehende Storage-Hierarchie (`StorageRoom/Shelf/Slot`). +**Aufwand:** 1,5–2,5 PT. + +--- + +## D. Klärungspunkte (vor Umsetzung) + +| # | Frage | Betrifft | +|---|---|---| +| **D-1** | Was steht in WooCommerce **je Variation** im SKU-Feld — exakt die ERP-`wp_number` (z. B. `100009`, `100029`) oder ein anderes Schema/Custom-Feld? Hat das Elternprodukt eine SKU, und soll sie je als Fallback dienen? Gibt es Altprodukte, die wirklich das „Basis-Nr. + Suffix"-Schema (`10042-1`) nutzen? | AP-34 | +| **D-2** | Produktebene: Reicht die Annahme **1 g/ml** (Rezeptursumme = Füllmenge in ml), oder braucht es ein separates **Netto-Gewichtsfeld (g)** je Produkt? Der Kunde erwartet 50 ml → 50 g. | AP-35 | +| **D-3** | Läuft im Shop der Cron `partnercenter_api_fetch_orders_status` und sind die API-Zugangsdaten gültig? (Zuerst prüfen — vermutlich die eigentliche Ampel-Ursache.) Farbsemantik für `Abholung`/`storniert`? | AP-38 | +| **D-4** | Soll der **Wareneingang** künftig eine **ml-Erfassung** bekommen (Enum `unit` um `ml` erweitern), damit die Dichte-Umrechnung greift? Für welche Rohstoffe ist Dichte relevant? | AP-42 | +| **D-5** | Produktbestand: sollen **Eingang** und **Ausgang** getrennte Gründe-Listen haben oder eine gemeinsame? | AP-48 | +| **D-6** | Lagerort „Waldbröl": die 3 alten Wareneingänge auf **Köln umhängen** oder Ort nur **soft-löschen** (historische Zuordnung bleibt)? | AP-50 | + +--- + +## Empfohlene Reihenfolge + +1. **Zuerst Bugs mit Kundennutzen im Tagesgeschäft:** AP-37 (Doppelung, trivial), AP-36 (Textphasen), AP-35 → AP-40/AP-41 (Mengen korrekt + Bestand/Differenz + Phasensummen), AP-39 (Abwiege-Werte). +2. **AP-34 parallel** (braucht Shop-Abstimmung D-1 + Connector-Rollout). +3. **AP-38** nach Shop-seitiger Cron/Auth-Prüfung (D-3). +4. **AP-42** nach Entscheidung D-4 (Dichte). +5. **Funktionen B/C** nach den Bugs, jeweils nach Klärung. + +> Jedes AP wird einzeln umgesetzt, getestet (Pest) und committet (Konvention „Commit je Arbeitspaket"). Vor der Umsetzung bitte Abschnitt D beantworten. diff --git a/dev/product management /01-entwicklungsplaene/entwicklungsplan-aktualisiert-2026-08-26.md b/dev/product management /01-entwicklungsplaene/entwicklungsplan-aktualisiert-2026-08-26.md new file mode 100644 index 0000000..eeed22a --- /dev/null +++ b/dev/product management /01-entwicklungsplaene/entwicklungsplan-aktualisiert-2026-08-26.md @@ -0,0 +1,72 @@ +die WaWi macht richtig Spaß - danke nochmal für die tolle Umsetzung. An ein paar Stellen hakt sie noch was, teils durch Bugs, teils durch fehlende Funktionen. + + +Vorab: Was buggy bzw. dringend (!) ist, habe ich mit # am anfang markiert. Vielleicht hilft das bei der Priorisierung. + + +ZUORDNUNG ARTIKEL-NR. +# - Funktioniert noch nicht bei Varianten (das Thema, das ich Dir per WhatsApp geschickt hatte). Beispiel: +https://www.gruene-seele.bio/naturkosmetik-onlineshop/haeld-deo-creme-ohne-natron/ + +# Jede Variante hat ein eigenes Feld für eine eigene Artikel-Nr., ich glaube, dass das anders bezeichnet wird und deswegen nicht gefunden werden kann. Das müssen wir dringend beheben, da wir das aktuell manuell machen und im Versand immer höllisch aufpassen müssen. + + +NEUE PRODUKTION +# - Die Summen der Rohstoffe werden auf 100 g berechnet, nicht auf 50 g, wenn ich z.B. HAELD Sanft 50 ml plane - hier wird als noch nicht die richtige finale Menge aus dem Produkt gezogen + +- Ich möchte eine neue Produktion zwischenspeichern können, ohne dass ständig die Pflichtfelder aufmucken. Also den jetzigen Speicherbutton vielleicht umbenennen in „Produktion abschließen“ (da machen die Pflichtangaben Sinn). Aber gib uns noch 2-3 Buttons auf der Seite verteilt zum Zwischenspeichern, die den aktuellen Stand absichern. + +# - Auf Rezepturebene brauchen wir über der Phase A noch Textfelder ohne Rohstoffe (z. B. Hinweise für Vorbereitung / Nachbereitung). Ich habe das mal ausprobiert (bei HAELD Begehrt 50 ml) mit „neue Phase", aber die werden dann nicht angezeigt in der Produktion, wenn ich keinen Rohstoff ausgewählt habe. Bitte das auch ohne Rohstoffe möglich machen. + +- Ich möchte etwas aufhübschen, weil die Rezeptur fürs Auge etwas unübersichtlich ist: + a) Eine Phase in der Rezeptur hat eine Outline - die kann bleiben. Da drin ist dann nochmal ein Kasten/Outline um die Chargen-Dropdowns - die bitte weg. Den gesamten Kasten einer Phase bitte ganz leicht farblich hinterlegen (3-5% maximal). Die Phasen sollen sich einfach optisch voneinander trennen. Ist leichter fürs Auge. + b) Die Schriftgrößen (Beschreibung Phasen, Dropdowns etc.) bitte alle gleich groß und auch schwarz - so wie in der INCI-Liste oben in der Herstellerrezeptur +# c) am ipad kann ich die Textfelder mit dem Finger nicht „anfassen“ und nach unten großziehen. Was machen wir da? + d) Die Beschreibung der Phasen bitte formatiert darstellen wie ich das auf Produktebene eingegeben habe. Man kann die langen Texte leider so aneinandergereiht nicht gut lesen. + +# - Die Zahlen, die ich nach Abwiegen neben die Chargen eintrage, müssen abspeicherbar sein. Die müssen nicht aufs Gramm passen. Macht ja auch keinen Sinn, wir wollen ja den realen Abzug aus dem Rohstoffbestand haben. Lass die orange-grün Optik aber bitte bestehen: ORANGE = nix eingetragen; GRÜNE = Wert ist eingetragen und hat eine maximale Abweichung von 5% nach oben oder unten (so stellen wir sicher, dass nicht irgendein Nonsens oder eine Ziffer zuviel eingetragen wurde) + +- Bitte sicherstellen, dass die Rohstoffe sich aus dem oberen Teil im Bestand reduzieren, aber die Verpackungselemente (Etikett, Tiegel etc.) NUR aus dem Produktionsergebnis. + +- Die INCI-Liste oben bitte sortiert nach der höchsten Einsatzkonzentration, also absteigend + +- Bitte in der Auswahl oben nur Produkte anzeigen, die „produktionsrelevant“ sind. Ich brauche dazu noch einen weiteren Knopf auf Produktebene. Denn ich will auch nur eine Größe drin haben. Beispiel: Deobalm SANFT gibt es in 50 ml und 5 ml. Beide haben zwar eine Herstellerrezeptur, aber wir kalkulieren immer nur auf Basis der 50 ml Variante, aus der Masse erstellen wir dann auch die 5 ml. Ich brauche also nicht alle Produktvarianten in der Liste und die Aloe Produkte schon gar nicht. Wenn ich also ein Produkt auf „nicht produktionsrelevant“ stelle, erscheint es dort nicht. + +# - Bei neuer Produktion möchte ich noch zwei Spalten oben in der Tabelle mit den INCI der Hersteller-Rezeptur ganz rechts hinter „Regal“ haben: a) den aktuellen Bestand dieses Inhaltsstoffes und zum Schluss die „Differenz“. Beispiel: Ich brauche lt. Rezeptur 1.000 g Sheabutter (Gramm gesamt) | Raum 2 (Regal) | 832 g (Bestand) | -168 g (Differenz) / 168 g (Differenz) (also je nach Wert positiv oder negativ rot mit minus oder grün dargestellt). Außerdem: Überschrift „Regal“ in der Tabelle bitte in „Ablage“ umbenennen. + + +PRODUKTBESTAND +- Eingang buchen und Ausgang buchen - für beides möchte ich die „Gründe“ bitte selber editieren können unter „Einstellungen“ -> „Allgemeines“. + +INHALTSTOFFE +- Produkte -> Inhaltsstoffe -> z. B. Sonnenblumenöl: Hier gibt es das Dropdown „Lieferanten“. Da bitte nur die Lieferanten anzeigen, die mit „Rohstoffen“ zu tun haben. Wir mit allen Lieferanten zu unübersichtlich. + +LAGERORTE +- Ich kann Waldbröl nicht löschen - das wird nicht mehr gebraucht. Die Funktion aber trotzdem belassen. Bitte „Köln“ überall als Default einstellen, ich will das nicht immer auswählen müssen. + +ROHSTOFFBESTAND +- Ich gehe auf Rohstoffbestand und dann in ein einzelnes INCI rein. Da wird dann in der Box aufgezeigt, in welchen Produkten dieses INCI steckt. Hier möchte ich die Aloe Produkte ausgeblendet haben. Vielleicht können wir das mit der o.g. neuen Funktion „nicht produktionsrelevant“ verbinden. + +# - Geh mal auf Rohstoffbestand und dann in Brokkolisamenöl rein. Da werden Produkte doppelt aufgelistet in der Tabelle „Enthalten in“. + +AUF SEITE WOOCOMMERCE +# - Wir haben ja immer eine Ampel in unseren Shops, mit der wir mit Orange oder Grün erkennen, ob eine Bestellung abgeschlossen wurde. Das funktioniert beim Abhaken im Partnercenter noch nicht (sh. Screenshot dev/product management /01-entwicklungsplaene/PastedGraphic-1.png). Aktuell bleiben alle auf Orange anstatt auf Gründ zu switchen. + + +Nachtrag 1: + +NEUE PRODUKTION +# - Bitte den Kasten mit „Verpackung (Vorschau)“ nach oben unter die INCI-Tabelle. Dann sieht man auf einem Blick, was man alles braucht. +# - Bitte bei jeder Phase eine Gesamtsumme an Gramm (am besten in Klammern direkt hinter der Bezeichnung „Phase A (345 g)", damit man weiß, wie groß das Gefäß ist, das man fürs Rühren dieser Phase nehmen muss. + +LAGERORT +- Ich brauche bitte bei allen Elementen (nicht nur bei Rohstoffe, sondern auch Produkte, Verpackung etc.) die Felder für die Lagerung (Regal, Fach etc.). Die sollen dann auch an entsprechenden Orten angezeigt werden (Produktbestand; Produktverpackung) + +GEWICHT von Rohstoffen +# - Ich glaube es macht Sinn, wenn wir den Wert der Dichte eines Rohstoffes hinterlegen, damit ich weiß, wieviel Gramm wirklich da sind. Die Propolistinktur z. B. hat eine Dicht von ca. 0,79 g/ml, das heißt, wenn ich 100 ml Propolis Tinktur einkaufe, habe ich gerade mal 79 g da. + +# Vorschlag: Wir machen bei den Inhaltsstoffen ein Feld für die Dichte. Trage ich was ein, wird dieser Wert für die Berechnung der Grammzahl hergenommen (Rohstoffbestand). Bleibt es leer, greift das Gewicht wie „eingekauft“. + +# Das Eintragen des Faktors ist am Ende nur für „Überproduktion“ durch Verriss bei der Produktion. Das kann nicht diese Umrechnung kompensieren. Die Berechnung mit der Dichte spiegelt damit den wirklichen Rohstoffbestand wieder. + + diff --git a/dev/product management /README.md b/dev/product management /README.md index 688ded5..e5e77a4 100644 --- a/dev/product management /README.md +++ b/dev/product management /README.md @@ -91,6 +91,17 @@ Details: [Audit-Bericht](02-audit/audit-bericht-15-07-2026.md). --- +## Testphasen-Feedback 26.08.2026 → Plan V7.0 + +Aus der laufenden Testphase kam eine neue Feedback-/Bug-Runde. Alle Punkte sind am +Code **und** an der Live-DB verifiziert und in einen Umsetzungsplan überführt: +**[Entwicklungsplan V7.0](01-entwicklungsplaene/entwicklungsplan-V7-2026-08-26.md)** +(9 bestätigte Bugs + Erweiterungen, ca. 15–26 PT, AP-34…AP-51). Wichtig: die +WooCommerce-Ampel ist voraussichtlich **kein** Partnercenter-Fehler, sondern +shopseitig (Status-Cron/Auth). Rohfassung des Feedbacks: +[entwicklungsplan-aktualisiert-2026-08-26.md](01-entwicklungsplaene/entwicklungsplan-aktualisiert-2026-08-26.md). +Offene Klärungspunkte (D-1…D-6) im Plan blockieren den Start einzelner Pakete. + ## Offene / nachgelagerte Pakete (nach Kundentestphase) Kundenentscheid 16.07.2026: erst nach der Testphase. Grober Restaufwand **ca. 28–42 PT**.