Die Einheit hing bisher als Anhang rechts am Mengenfeld — auf breiten
Monitoren außer Sicht, und „g" war stiller Default. Jetzt:
- Eigenes Pflichtfeld „Einheit der bestellten Menge" direkt VOR der Menge
mit „Bitte wählen"; beim Neuanlegen muss bewusst Gramm oder Milliliter
gewählt werden, beim Bearbeiten ist die gespeicherte Einheit vorbelegt.
- Hinweis unter der Einheit sagt, ob ml möglich ist (Dichte hinterlegt,
Wert wird genannt) oder erst gepflegt werden muss; ml bleibt ohne Dichte
gesperrt. Mengen-Hinweis und ml→g-Live-Vorschau folgen der Auswahl.
- Server: Store-/UpdateStockEntryRequest weisen Rohstoff-Einkäufe ohne
Einheit ab (Verpackung bleibt ohne Einheit). Bestehende Tests ergänzt,
neuer Test für die Pflicht.
- In-App-Doku (Hinweise, Testleitfaden) nachgezogen.
Suite: 390 grün.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Ergänzt die selbsterklärende Dichte um eine fette Live-Vorschau direkt am
Mengenfeld — in beiden Stufen des Wareneingangs:
- Einkauf erfassen (Stufe 1): bei Einheit „ml" zeigt sich beim Tippen
„<ml> ml × <Dichte> g/ml = <g> g"; der Hinweistext bleibt Führung.
- Wareneingang buchen (Stufe 2): gleiche Vorschau am Feld „Eingegangene
Menge", wenn in ml eingekauft wurde.
So ist an jeder Eingabestelle sofort sichtbar, wie und wann die Dichte
rechnet. Kein Mechanik-Wechsel; Speicherung bleibt in Gramm.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Die Dichte (g/ml) wirkte "unverbunden": Sie wird nur beim Einkauf in ml
gebraucht (ml × Dichte = Gramm), der Bestand läuft immer in Gramm. Wer in
Gramm erfasst, sah die Dichte nirgends wirken. Zudem verschwamm sie mit dem
daneben stehenden Schwundfaktor.
- Rohstoff-Formular: Hilfetexte trennen beide Faktoren eindeutig
(Schwundfaktor = Rezeptur/Produktion, Dichte = nur ml-Einkauf) und die
Dichte zeigt eine Live-Vorschau „1 ml = x g / 100 ml = y g".
- Rohstoffbestand-Detailseite: Dichte als Stammdatum mit Kurzerklärung
eingeblendet, damit der Wert dort sichtbar ist, wo der Bestand steht.
Kein Mechanik-Wechsel; Umrechnung/Speicherung in Gramm bleiben unverändert.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
- exclude_single_commission: Rollen (z. B. Barkunde 0 %) ziehen den
produktseitigen Kunden-Einzelrabatt (single_commission/value_commission)
nicht mehr ab. Behebt: 0-%-Rolle zog trotzdem die Produktprovision.
- hide_registration: interne Rollen (z. B. Mitarbeiter) werden im Wizard
und der Mitgliedschafts-Auswahl ausgeblendet, bleiben im Admin/Lead
(HTMLHelper) weiter zuweisbar.
- Migration 2026_09_11_100000 (beide Flags, Default false), Model-casts/
fillable, Admin-Formular (2 Checkboxen), Warenkorb-Gate in Yard.
- Test tests/Feature/UserLevelSingleCommissionTest.php.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
- Stats\Sales: alle Summenzeilen (Angezeigt/Ausgeblendet/Gesamt/Rabatte/Netto)
aus price_net × qty der Positionen statt aus subtotal_full/discount des
Bestellkopfs; WooCommerce-Importe (txaction extern) hatten dort NULL und
zählten seit 06/2026 mit 0 € (Aug 2026: 449 € statt 3.318 € angezeigt)
- Kompensationsprodukte (comp > 0) bleiben in der Menge, neue Spalten
„davon Kompensation“ (aktuell + Vorjahr) und Summenzeile 9993
- Gelöschte Produkte bleiben im Umsatz sichtbar (withTrashed, „(gelöscht)“)
- WP-Import setzt subtotal_full und discount jetzt wie der Checkout
- Migration füllt subtotal_full/discount bestehender Extern-Bestellungen nach
- Excel-Export um die beiden Kompensationsspalten erweitert
- Test tests/Feature/StatsSalesVolumeTest.php (Konsistenz, Filter, Jahr)
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Bisher wurde durch fehlende geschweifte Klammern net_partner_commission
auch dann gesetzt, wenn der Sponsor inaktiv war - dann ohne m_sponsor_id.
Ergebnis: eine Provision ohne Empfaenger, die nie ausgezahlt wird
(getPartnerCommissionItems sucht ueber m_sponsor_id) und Auswertungen
verfaelschen kann. Jetzt werden m_sponsor_id und net_partner_commission
gemeinsam nur bei aktivem Sponsor gebucht.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Alle Positionen tragen jetzt genau einen Stundenwert statt einer Von-Bis-Spanne:
Mittelwert der bisherigen Planschätzung geteilt durch fünf, auf halbe Stunden
gerundet, Minimum 0,5 Std. Ergebnis: 188 Std. Entwicklung + 43 Std.
Qualitätssicherung = 231 Std. gesamt, 26,5 Std. nachgelagert.
PT-Spalte entfernt, Methodik-Abschnitt entsprechend neu gefasst (ausgewiesen
ist der reale Aufwand, nicht der marktübliche Planwert).
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Neues Kundendokument in 03-status-und-vorschlaege: Aufschlüsselung der
Entwicklung März–September 2026 nach Datum und Teilmodul (Phasen 1–6, mit
Commit-Nachweis je Zeile) sowie alle 81 Befunde aus fünf Prüfungen mit
Stundenschätzung je Befund. Leistungsübersicht 23.07.2026 als Vorgänger
markiert, README auf das neue Dokument umgestellt.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Prüfbericht pruefung-ap53-mengenpraezision-2026-09-10.md, alle Punkte umgesetzt:
- AP53-01: Toleranz nur noch in ProductionService (TOLERANCE_RATIO 0,05, TOLERANCE_FLOOR 0,005, COMPARE_EPSILON); das Produktions-JS rendert die Konstanten aus dem Service statt eigener Zahlen (Ampel hatte noch Sockel 0,05 g).
- AP53-02: withinTolerance() vergleicht mit Float-Ausgleich 1e-9 — 0,025 g auf 0,020 g Soll ist wieder zulässig, 0,026 g nicht; Sollwerte werden nicht gerundet.
- AP53-03: Chargen-Hauptzeile und Standortsumme im Rohstoff-Detail mit formatWawiQuantity(…, 0) (0,125 g statt 0 g).
- AP53-04: Ausschuss-Fehlermeldungen (Request ohne/mit Charge, Controller-Wiederholung) mit formatWawiQuantity().
- 4.1: Obergrenze decimal(12,3) bewusst akzeptiert (Live max. 49.000 g) und als InventoryService::QUANTITY_MAX validiert; Bereichsprüfung + Rollback-Hinweis in der Deploy-Checkliste.
- 4.2: normalizeWawiQuantity() (parsen + drei Stellen) in Bestell-/Wareneingangs-/Ausschuss-Requests, parseQuantity() rundet kanonisch für batch_key- und stock_entry_id-Zeilen; Untergrenze 0,001 g; ml-Eingaben, die umgerechnet 0,000 g ergeben, werden abgelehnt (Store/Update/Receive).
- 4.3: Einkaufs-JS trennt formatQuantity (3), formatPrice (2, wie vor AP-53) und formatDensity (4).
- 4.4: Hinweise präzisiert (Übersichten ganzzahlig, Rundungs-/Untergrenzregel), Leitfaden §26 mit Sockelrand-, Hauptzeilen- und Meldungs-Prüfschritten, Plan V7 und README aktualisiert, Prüfbericht Abschnitt 6 mit Nacharbeitsstand.
Tests: QuantityPrecisionTest +6 (AP53-01…04, 4.2 Rundung/Untergrenze/Obergrenze, ml→0 g). Suite 384 grün / 1.592 Assertions.
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Kundennachtrag 09.09.2026: Ist-Mengen je Charge in der Produktion sollen auf das Milligramm eingegeben werden können (z. B. 0,125 g). Bisher rundeten Datenbank (decimal 12,2), Bestandslogik, Anzeige und Toleranzsockel auf zwei Stellen; „0,125" wurde still zu 0,13, „0.125" nach der Punkt-Regel zu 125 g.
- Migration 2026_09_09_100000: production_ingredients.quantity_used, stock_entries.ordered_quantity/received_quantity, stock_disposals.quantity → decimal(12,3); Casts decimal:3. Auf der Dev-DB (Live-Kopie) ausgeführt, 53/78/7 Zeilen unverändert.
- InventoryService::QUANTITY_DECIMALS = 3; roundWawiQuantity() ersetzt alle round(…, 2) in InventoryService, ProductionService, StockDisposalController/-Request, StockEntryRepository/-Controller, RawMaterialStockController.
- formatWawiQuantity($v, $min = 2): bis drei Stellen, mindestens zwei — Produktionsdetail, Einkauf Liste/Detail/Formular, Ausschuss-Liste, Chargen-Rest im Rohstoff-Detail.
- Eingaberegel (reFormatWawiNumber, JS parseGerman/parseNumber): zusätzlich „0.xxx" als Dezimalzahl; „1.500" bleibt 1500. Produktions-JS: fmt() bis drei Stellen, fmtInput() schreibt gespeicherte Zahlen deutsch ins Feld (1,125 statt 1.125 = 1125).
- Soll-Ist-Toleranz: Sockel 0,05 → 0,005 g; Ausschuss min 0,001.
- Doku: Hinweise (Neu/geändert), Leitfaden Version 3.1 mit Abschnitt 26, Plan V7 AP-53, README (Deploy-Checkliste, Suite 378).
Tests: QuantityPrecisionTest (6) — Parsing, Anzeige, Produktion 0,125 g exakt + Rest 9,875 g, Entwurf 1,125 wiederöffnen, Toleranz Kleinmengen, Ausschuss 0,005 g.
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Kundenfeedback 09.09.2026: Das Kästchen „Produktionsrelevant" oben im Produktformular wurde nicht gefunden. Es sitzt jetzt in der Karte „Warenwirtschaft" direkt unter „Im Produktbestand anzeigen", heißt „In der Produktion anzeigen (Produkt wird selbst hergestellt)" und erklärt im Hilfetext die Wirkung (Zukaufartikel wie Aloe abwählen: keine Anzeige in der Produkt-Auswahl der Produktion und in „Enthalten in"; Produktionsergebnis, Produktbestand und Verkauf unberührt). Feld hält jetzt auch old()-Werte nach Validierungsfehlern.
In-App-Doku (Hinweise, Leitfaden §13/§20) entsprechend umformuliert; Test prüft Label und Platzierung.
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Nachfrage 09.09.2026 (Zukaufartikel wie Aloe sollen in der Produktion nicht auftauchen): Die Funktion existiert seit AP-47 (Checkbox am Produkt, Filter im Planungs-Dropdown und in „Enthalten in"). Bisher war nur der Dropdown-Filter getestet; der neue Test sichert den ganzen Weg Formular → Speichern → Produktions-Auswahl ab.
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Auf Live trat unter /admin/inventory/general ein 500er auf ("Route [admin.inventory.stock-movement-reasons.create] not defined"). Die Route existiert seit AP-48 (190713c) in routes/web.php und ist getestet; Ursache ist ein veralteter Route-Cache auf Live. Schritt 5 der Checkliste fordert jetzt optimize:clear + Neuaufbau der Caches als Pflichtschritt.
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Der SalesController rief InvoiceRepository::createCancellation() auf, die Methode existierte aber nicht — jeder Storno-Versuch endete im 500er. Die Stornorechnung wird jetzt aus demselben Nummernkreis wie die Rechnung erzeugt (pdf.cancellation_invoice, Rechnungs-Briefpapier), als cancellation_invoice am Auftrag gespeichert und der Zähler erhöht.
Optional geht eine Storno-Mail mit angehängter Stornorechnung (MailCancellation, Texte email.cancellation_title/_copy1line) statt der Rechnungs-Mail an den Kunden.
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
- resources/docs/hinweise.md: Abschnitt „Neu / geändert 08./09.09.2026“ (alle
nutzerrelevanten Nachbesserungen + AP-52), Spalte „Lagerort“, Entwurfsregeln,
Versand nur versandfertig, Köln-Default auch im Ausschuss.
- resources/docs/testleitfaden.md: Version 3 mit Teil C (Abschnitte 19–25).
- README: Deployment-Checkliste (Migrationen 2026_09_08_* auf Dev-DB gelaufen),
In-App-Doku als maßgebliche Nutzerdoku; docs/testleitfaden V1 als Archiv markiert.
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Je Verpackungsartikel Bestand (Stück), Differenz zu Bedarf (rot/grün wie bei
Rohstoffen, AP-40) und Lagerplatz; Spalte einheitlich „Lagerort“ für Rohstoffe
(INCI-Tabelle, vorher „Ablage“) und Verpackung.
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Ob der Snapshot gilt, entscheidet der Buchungsstatus (nicht die Zeilenzahl);
ohne Verpackung gebuchte Produktionen zeigen „Kein Verpackungsverbrauch gebucht“.
Tests R-01/R-02.
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
mfg_phase_id[] je Phasenblock; Zuordnung bestehender Phasen über ID, dann Name,
dann gemeinsame Rohstoffe. Ein vorangestellter neuer Block übernimmt nicht mehr
die ID einer umbenannten Phase; Produktionszeilen behalten ihre Phase.
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Formular, Update-Validierung und Repository nutzen bei unverändertem Rohstoff den
Snapshot als Rückfall; bei Rohstoffwechsel wird keine fremde Dichte übernommen.
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Bearbeitungsformular gebuchter Produktionen liefert Snapshot und Ergebnissummen;
die Vorschau folgt derselben Regel wie die Speicherung (F-05) und weist auf eine
Neuberechnung hin, sobald sich Produktsummen ändern. Tests N-01/N-02/N-04.
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
- N-01: Ist-Menge ohne gewählte Charge bleibt im Entwurf erhalten (Filter in
Request und Service, formBatchKey liefert '' für chargenlose Zeilen).
- N-03: outputSignature summiert Stückzahlen je Produkt — ein Chargensplit
ersetzt den historischen Verpackungs-Snapshot nicht mehr.
- N-05: Ausschuss ohne Chargenbezug (Altbestand) wird für die Verfügbarkeit je
Standort FEFO auf die Chargen angerechnet (applyUnboundDisposals, lesend);
Chargen-Ausschussprüfung nutzt dieselbe Verfügbarkeit.
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Phasen werden über Name/Reihenfolge den bestehenden zugeordnet und aktualisiert;
nur entfernte Phasen werden gelöscht. Produktions-Verbrauchszeilen behalten so
ihre recipe_phase_id. Derselbe Rohstoff je Phase nur einmal (Validierung).
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
- Statusservice: Vorbedingung (Ausgangsstatus, Zahlungsfreigabe) wird nach
lockForUpdate erneut geprüft (Board übergibt sie als Closure).
- Wareneingang: Transaktion + Sperre, „offen“ wird innerhalb der Sperre geprüft.
- Ausschuss: betroffene Wareneingänge sperren und Restbestand in der
Transaktion erneut prüfen.
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Einheit, ml-Menge und Dichte-Snapshot werden übernommen; fehlt die
Rohstoff-Dichte inzwischen, greift der Snapshot der Vorlage.
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Nur Hersteller-Rezeptur, alle Phasenzeilen je Produkt summiert, Skalierung
über Füllgewicht und Faktor wie in der Produktion; kein roher Pivot-Wert mehr.
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Board-Statuswechsel auf „versendet“ prüft serverseitig isReadyToShip()
(Rechnung/API weiterhin erlaubt); Button im Board ohne Freigabe deaktiviert.
Konfektionieren bleibt vor Zahlungseingang möglich.
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Ohne Charge wird gegen den Restbestand des gewählten Lagerorts geprüft und die
Menge FEFO auf die dort verfügbaren Chargen verteilt (je Charge gebucht, in
einer Transaktion) — wie der Produktionsverbrauch. Gesamt-, Standort- und
Chargenbestand stimmen damit überein.
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Stückliste je Ergebnisprodukt wird ins Formular gegeben; die Vorschau rechnet
Outputs × Stückliste (wie die Buchung) und reagiert auf Hinzufügen/Entfernen,
Produkt- und Mengenwechsel.
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Vorbelegung der Chargen-Zeilen zentral in ProductionController::existingLines();
old('ingredient_lines') hat Vorrang vor dem gespeicherten Stand.
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
updateProduction() baut die Verpackungszeilen nur neu auf, wenn sich
Ergebnisprodukte/Stückzahlen ändern oder ein Entwurf abgeschlossen wird.
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
production_ingredients.recipe_phase_id; Formular sendet die Phase je Zeile,
Vorbelegung je Rohstoff|Phase. Altbestand ohne Phase wird nur einmal eingesetzt.
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Entwürfe speichern batch_key roh (stock_entry_id nullable), keine Auflösung
und keine Filterung unfertiger Zeilen mehr beim Zwischenspeichern. Eine nicht
mehr verfügbare Charge wird im Formular markiert statt alle Zeilen zu verwerfen.
Ergebniszeilen dürfen im Entwurf ohne Stückzahl bleiben. Auflösung, Prüfung und
Buchung erst beim Abschluss.
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Planung oben bleibt auf produktionsrelevante Produkte gefiltert (AP-47);
Ergebniszeilen bieten alle aktiven Einzelprodukte plus bereits gespeicherte
Output-Produkte an (Bearbeiten/Kopieren verliert keine Zuordnung mehr).
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
consumedByStockEntry() schließt Entwürfe jetzt wie remainingByIngredient()
aus. Regression: Chargen-/Standortbestand, zweite Produktion, Ausschussprüfung.
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
- resources/docs/hinweise.md: Stand 28.08.2026; neuer Block „Neu in Runde V7.0"
(AP-34/35/38/39/40/41/42/43/44/45/46/47/48/49/50/51) unter „Bereits nutzbar";
zentrale Verhaltens-Hinweise ergänzt (Füllgewicht/Soll, Dichte/ml, Entwurf vs.
Abschließen, Varianten & Aktions-Kopien, Lagerplatz Produkte/Verpackung).
- resources/docs/testleitfaden.md: auf Version 2 gehoben. Teil A = bisherige
Basis-Abschnitte 1–11 (unverändert), neuer Teil B = Abschnitte 12–18 mit
Test-Schritten für die V7.0-Funktionen (Stammdaten/Produkt/Rohstoff/
Wareneingang/Produktion/Entwurf/Verpackung/Versand). Wird über NoticeController
(Einstellungen → Leitfaden) ausgeliefert.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Kunde hat den eigentlichen Varianten-Fall präzisiert (28.08.): 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, der auf die Kernnummer gebucht werden muss.
Der bestehende Importer macht das bereits korrekt (volle SKU zuerst, sonst
„-"-Split auf die Kernnummer). Da wp_number eine Integer-Spalte ist, kann keine
echte Artikelnummer einen „-" enthalten — dashed SKUs fallen also immer sauber
auf die Kernnummer zurück, eigenständige Nummern treffen ihr eigenes Produkt.
Nur Doku korrigiert: Kommentare im ShoppingUserController und der Testname waren
als „Legacy-Fallback" fehletikettiert — es ist der beabsichtigte Mechanismus für
Shop-Duplikate. Kommentar erklärt jetzt beide Fälle; Test umbenannt auf
„shop-duplikat kernnummer-suffix bucht dasselbe kern-produkt". Keine Logikänderung.
Suite 338 grün.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
