Kevin Adametz c7ddf7906e Warenwirtschaft: Plan V7.0 — AP-34 Shop-Duplikat-Konvention dokumentiert

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

2026-08-28 11:54:12 +00:00

23 KiB

Raw Blame History

Entwicklungsplan V7.0 — Testphasen-Feedback 26.08.2026

Stand: 26.08.2026 · Basis: Kundenfeedback aus der Testphase (entwicklungsplan-aktualisiert-2026-08-26.md) Vorgänger: V6.0 (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.

Umsetzungsstand (26.08.2026)

AP	Status
AP-37 Doppelung „Enthalten in"	✅ erledigt (Commit `00be848`)
AP-36 Rezeptur-Textphasen	✅ erledigt (`d60947c`)
AP-35 Mengen auf Füllgewicht	✅ erledigt (`744b36c`) — Migration `fill_weight` auf Dev-/Live-DB gelaufen
AP-39 ±5 % Abwiegen + Ampel	✅ erledigt (`744b36c`, zusammen mit AP-35)
AP-40 Bestand/Differenz-Spalten, „Regal"→„Ablage"	✅ erledigt (`4c6a57b`)
AP-41 Verpackungs-Vorschau oben, Phasen-Gramm	✅ erledigt (`4c6a57b`)
AP-45 Verpackung aus Produktionsergebnis	✅ erledigt (`d51860a`)
AP-46 INCI nach Konzentration sortiert	✅ erledigt (`e6007ef`)
AP-47 „produktionsrelevant"-Flag + Filter	✅ erledigt (`d51860a`) — Migration auf Dev-/Live-DB; löst auch „Aloe ausblenden"
AP-42 Rohstoff-Dichte (g/ml) + ml-Erfassung	✅ erledigt (`fa85234`) — Migration auf Dev-/Live-DB
AP-49 Lieferanten-Dropdown nur Rohstoff-Lieferanten	✅ erledigt (`4eb3648`)
AP-50 Waldbröl löschbar (→ Köln) + Köln-Default	✅ erledigt (`e08c8de`)
AP-48 Buchungsgründe getrennt Ein/Aus, pflegbar	✅ erledigt (`190713c`) — Migration auf Dev-/Live-DB
AP-34 Varianten-Artikelnummer	✅ erledigt (`8c938ee`) — ⚠️ Connector v1.6.0 muss in den Shop ausgerollt werden
AP-51 Lagerplatz-Felder Produkte & Verpackung	✅ erledigt (`30d4e28`) — Migration auf Dev-/Live-DB
AP-43 Zwischenspeichern (Entwurf) + „abschließen"	✅ erledigt (`abd202a`) — Migration `status` auf Dev-/Live-DB
AP-44 Rezeptur-Darstellung (Optik/iPad)	✅ erledigt (`2a6daf2`)
AP-38 WooCommerce-Ampel (Cron/Auth)	✅ erledigt (`0c8d321` ERP+Connector, `b6ca332` Cron-Selbstheilung) — Live-Ursache behoben
übrige APs	—

Suite: 338 grün. Erledigt: AP-34…AP-51 vollständig (AP-34/35/36/37/38/39/40/41/42/43/44/45/46/47/48/49/50/51). Keine offenen APs mehr. Verbleibend nur der Connector-Rollout v1.6.0 in den Shop (AP-34 + AP-38).

AP-43-Hinweis: „Zwischenspeichern" legt die Produktion als Entwurf ab (kein Bestand gebucht, keine Pflichtfeld-Prüfung); erst „Produktion abschließen" bucht Roh-/Produkt-/Verpackungsbestand. Entwürfe zählen nirgends in den Bestand. Eine bereits abgeschlossene Produktion kann nicht zurück in den Entwurf.

Rollout-Hinweis AP-34: Der ERP-Teil ist live-fähig (matcht die volle Variations-SKU gegen wp_number, „-"-Split nur noch Fallback). Der Shop zeigt die korrekte Zuordnung aber erst, wenn das Connector-Plugin v1.6.0 (dev/partnercenter-api/, sendet ab jetzt die Variations-SKU statt der Eltern-SKU) im WooCommerce-Shop installiert ist. Vorbedingung: jede Variation braucht im Shop eine gepflegte eigene Artikel-Nr. (SKU) = die wp_number des jeweiligen ERP-Produkts.

Modell-Bestätigung AP-34 (28.08.2026, mit Kunde geklärt): Es gibt zwei bewusst unterschiedene Fälle:

Physisch verschiedene Produkte (50 ml vs. 5 ml, mit/ohne Natron) = im Shop eigene Produkte mit eigener Artikelnummer, im ERP eigene wp_number, Bestand je Variante getrennt. Kein Zusammenfassen auf ein „Basisprodukt" (würde bei verschiedenen Größen den Bestand verfälschen). Zuordnung über die volle Artikelnummer.

Shop-Duplikate desselben Produkts: Kopiert ein Anwender ein Produkt für eine Aktion / ein neues Bild, verlangt WooCommerce eine eindeutige SKU → Konvention Kernnummer + Suffix (100500, 100500-a, 100500-b). Derselbe physische Artikel ⇒ muss auf die Kernnummer gebucht werden. Genau dafür der --Split (greift, wenn die volle SKU selbst kein eigenes Produkt trifft).

Weil products.wp_number eine Integer-Spalte ist, kann eine echte Artikelnummer nie einen „-" enthalten — SKUs mit „-" fallen also immer sauber auf die Kernnummer zurück, eigenständige Nummern treffen ihr eigenes Produkt. Beide Fälle sind durch die Reihenfolge (volle SKU zuerst, dann Kernnummer-Split) korrekt abgedeckt; keine Code-Änderung nötig (nur Kommentare/Test klargestellt, Commit f42e5a8). Kontrolle im Betrieb über die Übersicht „API-Bestellungen" (Protokoll „article not found" + Warnungen doppelte/fehlende WP-Nummern). Hinweis: eine Aktions-Kopie mit abweichendem Preis wird trotzdem korrekt auf das Kern-Produkt gebucht, erhält im Protokoll nur einen informativen „different price"-Vermerk.

AP-38 — WooCommerce-Ampel: Diagnose & Behebung (28.08.2026)

Ergebnis der Shop-Diagnose (SSH, 28.08.2026): Die orange Ampel war kein ERP-Fehler. Das ERP lieferte durchgehend korrekt sent/close für versendete Bestellungen (Live-DB: 111× shipped=2, 1× shipped=3).

Tatsächliche Ursache (shopseitig): Der stündliche Status-Cron-Hook partnercenter_api_fetch_orders_status war in WP-Cron gar nicht eingeplant (wp cron event list | grep partnercenter → leer). WP-Cron selbst lief einwandfrei (System-Crontab trifft wp-cron.php alle 5 Min, DISABLE_WP_CRON=1 also korrekt kompensiert) — aber ohne eingeplanten Event pollte nichts /api/wp/status, sodass jede Bestellung auf ihrem Initialwert open (orange) hängen blieb. Grund: Der Event wurde nur im register_activation_hook eingeplant und im Deaktivierungs-Hook gelöscht; ein In-Place-Plugin-Update (ohne echte Reaktivierung) ließ ihn dauerhaft verschwinden.

Behebung:

Live-Sofortfix (CLI, erledigt 28.08.): wp cron event schedule partnercenter_api_fetch_orders_status now hourly, danach wp cron event run …. Ergebnis: Warteliste _partnercenter_api_unclear_order_ids vollständig abgearbeitet (Ausgabe []) — alle offenen Bestellungen auf den korrekten Status aktualisiert, Ampel grün.
Dauerhafter Code-Fix (Connector v1.6.0, b6ca332): partnercenter_api_ensure_cron() auf init plant den Event bei jedem Request nach, falls er fehlt → selbstheilend, übersteht künftige Updates. Doku dazu im neuen dev/partnercenter-api/README.md.
ERP-/Connector-Mapping-Lücken geschlossen (0c8d321): ERP shipped=5 (Wartestellung) lieferte bisher free (im Shop kein Licht) → jetzt process (orange). Connector-Ampel kennt jetzt pick_up (Abholung → grün) und cancel (storniert → rote Kugel), beide vorher ⚠️; Endzustände fallen aus der stündlichen Warteliste.

Status: ✅ Live behoben und dauerhaft im Connector abgesichert. Die Punkte 2 + 3 gehen mit dem v1.6.0-Rollout (zusammen mit AP-34) in den Shop; der Live-Betrieb ist durch den CLI-Sofortfix bereits korrekt.

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. Kundenentscheid 26.08.2026 (D-1): Jede Variante hat ihre eigene Artikelnummer (zusätzlich zur internen Varianten-ID von WooCommerce). ⇒ Der Connector muss die Variations-Artikelnummer senden; das genaue Feld wird bei der Umsetzung an einer echten Bestellung verifiziert. Ursache (zwei zusammenwirkende Fehler):

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.
Importer zerschneidet die SKU. ShoppingUserController::prepareOrder() (:728) 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), ProductionService::requiredGramsByIngredient (:300), 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) × Füllgewicht(g) × factor × qty, konsistent an allen drei Stellen + INCI-Spalten. Kundenentscheid 26.08.2026 (D-2/D-4): Grundsätzlich wird in Gramm gerechnet, aber über ml + Dichte. Am Produkt daher optionales Füllgewicht in Gramm (bzw. Dichte g/ml auf contents_total); ist es leer, gilt contents_total als Gramm (1 g/ml). So ergibt „50 ml" korrekt 50 g bzw. das reale Gewicht bei abweichender Dichte. Aufwand: 1–2 PT (inkl. Produkt-Füllgewichtsfeld) · Bezug: AP-42 (gleiches Gramm/ml/Dichte-Prinzip auf Rohstoffebene).

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) 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. Kundenentscheid 26.08.2026 (D-4, = Antwort auf D-2): Es wird in Gramm geführt, aber Erfassung auch in ml möglich; über die hinterlegte Dichte ergeben sich die Gramm. Umsetzung bestätigt. Lösung: Nullable-Feld ingredients.density (g/ml) + ml-Erfassung im Wareneingang (Enum unit um ml erweitern). Ist Dichte gesetzt und wird in ml erfasst, wird bei der Buchung ml × density in Gramm umgerechnet und wie bisher als Gramm gespeichert (Aggregationen in InventoryService unverändert). Leeres Feld = Gewicht wie eingekauft. Aufwand: 1,5–2,5 PT.

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. Kundenentscheid 26.08.2026 (D-5): Eingang und Ausgang haben getrennte Gründe-Listen, beide pflegbar. Lösung: Eigene CRUD unter Einstellungen → Allgemeines nach Vorbild DisposalReasonController/SettingCrudController (Modell + Tabelle + FormRequest + Views) mit direction-Spalte (in/out) → zwei getrennt pflegbare Listen; mit den heutigen Werten geseedet. Aufwand: 1–1,5 PT.

Befund: IngredientController (:49) 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. Kundenentscheid 26.08.2026 (D-6): Waldbröl gibt es nicht mehr — alles ist Köln; die 3 Alt-Einträge auf Köln umhängen. Die Standort-Funktion muss aber erhalten bleiben (künftig könnte ein weiterer Standort dazukommen). Lösung: (a) Alt-Wareneingänge von Waldbröl auf Köln umbuchen, dann Waldbröl löschen/soft-deleten; die Guard-Logik bleibt für belegte Orte bestehen. (b) Köln als Default auch im Wareneingang (StockEntryController + _form.blade.php:88) und in weiteren Auswahlorten. Aufwand: 0,5–1 PT.

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 — beantwortet (Kundenentscheide 26.08.2026)

#	Frage	Antwort des Kunden	Betrifft
D-1	Wo im Shop liegt die Artikelnummer der Variante?	✅ Jede Variante hat ihre eigene Artikelnummer (+ interne Varianten-ID). Connector sendet künftig die Variations-Artikelnummer; genaues Feld bei Umsetzung an echter Bestellung verifizieren.	AP-34
D-2	Produktebene 1 g/ml oder eigenes Gewichtsfeld?	✅ In Gramm rechnen, aber über ml + Dichte. Produkt bekommt optionales Füllgewicht (g); leer = 1 g/ml.	AP-35
D-3	Läuft der Shop-Status-Cron / sind die Zugangsdaten gültig?	⏳ Wird kundenseitig geprüft. ERP-Mapping-Lücken (Status 5/pick_up/cancel) setzen wir unabhängig um.	AP-38
D-4	ml-Erfassung im Wareneingang?	✅ Ja — Erfassung in ml + Dichte je Rohstoff, Umrechnung auf Gramm. (= Antwort auf D-2.)	AP-42
D-5	Ein-/Ausgang gemeinsame oder getrennte Gründe?	✅ Getrennte, beide pflegbare Listen.	AP-48
D-6	Waldbröl umhängen oder soft-löschen?	✅ Alles auf Köln übernehmen, Waldbröl weg; Standort-Funktion für künftige Standorte erhalten.	AP-50

Damit ist nur noch D-3 offen (Shop-seitige Prüfung) — und blockiert lediglich die endgültige Ursachenbestätigung von AP-38, nicht die übrigen Pakete.

Empfohlene Reihenfolge

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).
AP-34 parallel (braucht Shop-Abstimmung D-1 + Connector-Rollout).
AP-38 nach Shop-seitiger Cron/Auth-Prüfung (D-3).
AP-42 nach Entscheidung D-4 (Dichte).
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.

23 KiB Raw Blame History Unescape Escape