odoo/odooapps
2
0
Fork 0
Code Issues Pull requests 6 Projects Releases Packages Wiki Activity Actions

[ADD] mrp_bom_baker_percentage: Rezepturen über Bäckerprozente #1

Open
odoo wants to merge 25 commits from odoo/add-mrp-bom-baker-percentage into 19.0 AGit
pull from: odoo/add-mrp-bom-baker-percentage
merge into: odoo:19.0
Conversation 0 Commits 25 Files changed 42 +6114
odoo commented 2026-09-21 20:12:32 +00:00
Owner
Copy link

Erster vertikaler Schnitt (62 % Wasser auf 10 kg Mehlbasis = 6,2 kg), plus PLAN.md mit dem festgehaltenen Entwurf. Test läuft grün gegen Odoo 19.0.

Erster vertikaler Schnitt (62 % Wasser auf 10 kg Mehlbasis = 6,2 kg), plus PLAN.md mit dem festgehaltenen Entwurf. Test läuft grün gegen Odoo 19.0.
Erster vertikaler Schnitt: eine Zeile mit "Wasser 62 %" ergibt auf einer
firmenweiten Mehlbasis von 10 kg eine Menge von 6,2 kg. Nur so viel Code, wie
dieser eine Test verlangt — Salz, Teigausbeute, Vorstufen-Rekursion und der
Vorstufenschutz folgen als eigene Schnitte.

PLAN.md hält den Entwurf fest, weil er über mehrere Runden entstanden ist und
an drei Stellen gegen die naheliegende Lösung ausfällt: feste Mehlbasis als
Feld auf res.company statt als ir.config_parameter (sonst folgt @api.depends
ihr nicht), kein Verlustfeld (Gär- und Backverlust sind die Differenz zwischen
Einsatz und Ausbeute einer Stufe), und drei getrennt ausgewiesene
Teigausbeuten statt einer.

Die Menge hängt an bakery_pct über Compute *und* Inverse, statt product_qty
als gespeichertes Computed Field zu überschreiben. Letzteres scheitert
doppelt: mrp gibt dem Feld default=1.0, und default_get wendet Defaults auch
auf gespeicherte Computes an, so dass die Berechnung nie läuft; ohne Default
fügt Odoo die Zeile ein, bevor es rechnet, und die NOT-NULL-Bedingung schlägt
zu. Der Umweg ist zugleich das bessere Verhalten, weil beide Richtungen
funktionieren.

Zielversion ist 19.0, nicht 20.0: was als Odoo 20 kursiert, ist master auf
version_info (19, 5, 0, ALPHA, 1) und zieht @odoo/owl >=3.0.0-alpha.31.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Zweiter Schnitt: eine Vorstufenzeile mit 30 % lässt 7 kg für die direkte
Mehlzeile übrig.

Die 100 %-Basis ist das Gesamtmehl einschließlich des Mehls, das über
Vorstufen hereinkommt. Der Bäcker gibt deshalb nur die versäuerte bzw.
vorverteigte Mehlmenge an -- die Zahl, mit der er ohnehin steuert -- und die
direkten Mehlzeilen bekommen den Rest. Bei genau einer Mehlzeile, dem
Regelfall, ist damit gar nichts einzutragen.

Eine Zeile gilt als Vorstufe, wenn ihr Produkt eine eigene Rezeptur hat. Der
Ausgleich hängt an create/write der Zeilen statt an einem Computed Field,
weil er Mengen quer über Geschwisterzeilen schreibt; eine Kontextschranke
verhindert, dass er sich dabei endlos selbst auslöst.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Schnitte 3 bis 6: Mehl je Ausgabeeinheit, Vorstufenmenge aus dem Mehlanteil,
Hochrechnung über mehrere Stufen, Gesamtmehl.

Der Mehlgehalt einer Vorstufe bezieht sich auf ihre AUSBEUTE, nicht auf ihre
Einsatzmenge. Eine Vorstufe verliert bei der Gärung Masse; bezöge man den
Gehalt auf den Einsatz, wäre jede darauf aufbauende Rechnung zu niedrig. Genau
deshalb braucht es kein Verlustfeld -- der Verlust steckt bereits in der
Differenz zwischen Einsatz und Ausbeute der Stufe.

Die Hochrechnung ist eine einzige Summe: jede Zeile trägt ihre Menge mal dem
Mehlgehalt ihres eigenen Produkts bei -- 1 für Mehl, 0 für Wasser und Salz,
und für eine Vorstufe deren eigener Wert. Damit setzt sich die Rechnung über
beliebig viele Stufen selbst fort, ohne Sonderfall für die Schachtelung. Der
Test dazu geht über zwei Ebenen: Anstellgut im Sauerteig im Teig.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Schnitte 7 und 9 plus ein Kalibriertest gegen ein echtes Rezept.

Die Hochrechnung ist jetzt rollenparametrisiert: eine Methode liefert den
Gehalt einer Rolle je Ausgabeeinheit, gleich über wie viele Stufen. Salz kam
damit als zwei Zeilen dazu -- ein gutes Zeichen, dass der Schnitt stimmt.

Brutto-TA zählt das gesamte Teiggewicht, die theoretische nur Mehl und Wasser.
Der Unterschied ist genau das Salz, und das ist keine Spitzfindigkeit: Plötz
gibt für das Neudorfer Sauerteigbrot TA 170 an, und das ist die Brutto-TA.
Eine naive Implementierung hätte 166 angezeigt.

Rezepturen laufen ab jetzt in GRAMM. Der Kalibriertest lief zuerst auf 10 kg
Basis und ergab 10,0034 kg Gesamtmehl; gemessen wurden 9,53 statt 9,5281 und
0,95 statt 0,9463. product_qty trägt digits='Product Unit', und in Odoo 19
teilen sich alle Einheiten diese eine Dezimalstelle -- in Kilogramm ein
10-Gramm-Raster, bei 200 g Salz also 5 % Fehler. In Gramm liegt dieselbe
Rundung bei 0,01 g. Die Alternative, die Dezimalstelle global anzuheben,
ändert eine datenbankweite Einstellung und gehört nicht in ein generisches
Modul.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Verhalten 10 bis 12 und 18. Zutaten bekommen einen Wasseranteil; die
tatsächliche TA zählt ihn mit, die theoretische nicht.

Der Unterschied ist an Vorstufen am deutlichsten: 6000 g Sauerteig bringen
3000 g Schüttwasser mit, 2000 g Milch weitere 1740 g gebundenes -- TA 130
theoretisch gegen 147,4 tatsächlich. Wer nur eine der beiden Zahlen kennt,
schätzt die Teigkonsistenz falsch ein.

Altbrot bindet Wasser, ist aber kein Mehl: es verschiebt die 100 %-Basis
nicht, sein Wasseranteil zählt in die tatsächliche TA. Fett bleibt in beiden
TA-Zahlen außen vor.

Verhalten 18 schreibt die Regressionsgarantie fest: eine Stückliste ohne
Rezeptart verhält sich unverändert wie Standard-MRP. Sie lief ohne eine Zeile
neuen Code grün -- was sie nicht überflüssig macht, sondern zu dem Netz, das
bei jeder künftigen Änderung anschlägt.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Verhalten 13 bis 15. Eine geschriebene TA landet in der Wassermenge; Mehl,
Salz und alles andere bleiben unberührt.

Schreibbar ist die TATSÄCHLICHE TA, nicht die theoretische. Der Plan sah
zuerst die theoretische vor, weil sie die einfachste Umkehrung hat. Das hält
der Regel nicht stand, dass ohne Wasserzeile die nächste Flüssigkeit mit
Wasseranteil angepasst wird: die theoretische TA zählt nur Schüttwasser, also
hätte eine Anpassung der Milch sie gar nicht bewegt und das Ziel wäre
unerreichbar gewesen. Im Normalfall -- es gibt eine Wasserzeile -- laufen
beide Zahlen ohnehin im Gleichschritt.

Vorstufen sind als Stellschraube ausgenommen: sie bringen Mehl mit und würden
die 100 %-Basis verschieben, statt nur die Teigfeuchte zu ändern.

Eine TA unterhalb des bereits gebundenen Wassers wirft. mrp hat dafür zwar
eine Check-Constraint, aber die meldet sich als SQL-Fehler; der Guard greift
vorher und nennt die niedrigste erreichbare TA.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Verhalten 16, 17 und 8. Damit ist die Liste abgearbeitet: 20 Tests, grün.

Die Sperre für geteilte Vorstufen liest ihren Zähler über eine METHODE, nicht
über das gleichnamige Feld. Die Abhängigkeit zeigt nach aussen -- auf Zeilen
fremder Stücklisten -- und die bildet @api.depends nicht ab. Gemessen: die
Suche fand zwei verwendende Rezepte, das Compute-Feld meldete weiter 0. Eine
Sperre, die auf einen eingefrorenen Zähler schaut, ist keine Sperre. Das Feld
bleibt als Anzeige bestehen.

"Als eigene Vorstufe ableiten" bricht die Sperre nicht auf, sondern stellt
ihre Vorbedingung her: die Kopie gehört danach zu genau einem Rezept. Der Test
prüft beide Seiten -- die Kopie ist editierbar, das Original unverändert und
das andere Rezept hängt weiter daran.

Der Backverlust ergibt sich aus Teigeinlage und Fertiggewicht, mit Umrechnung
zwischen Gewichts- und Zeileneinheit. Fehlt das Gewicht am Produkt, weist eine
Bedingung den Backschritt ab, statt still 0 % anzuzeigen.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Bis hierhin rechnete das Modul, ohne dass irgendwer es sehen konnte.

Im Kopf der Stückliste stehen jetzt Rezeptart und Kennzahlen, getrennt nach
Rezeptur und Backschritt. In der Zeilenliste eine Bäcker-%-Spalte; bei
Mehlzeilen ist sie schreibgeschützt, weil die den Rest auf 100 % zugeteilt
bekommen und der Bäcker dort nichts einträgt.

An Vorstufenzeilen hängen zwei Knöpfe: einer öffnet die Vorstufe in einem
eigenen Fenster, einer leitet eine rezepteigene Kopie ab. Eine geteilte
Vorstufe geht schreibgeschützt auf. Die eigentliche Sperre sitzt weiter im
Server -- ein Schreibversuch wirft ohnehin -- aber ein Formular gar nicht erst
zum Bearbeiten anzubieten ist freundlicher als eine Fehlermeldung beim
Speichern.

Am Produkt sind Rolle und Wasseranteil gepflegt; der Wasseranteil ist bei
Wasser ausgeblendet, weil dort die Rolle maßgeblich ist.

PLAN.md führt den Fortschritt mit: Verhaltensliste, die vier Stellen, an denen
die Tests den Entwurf widerlegt haben, und was als Nächstes ansteht.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Prozent und Menge rechneten für JEDE Zeile über den Mehlgehalt um. Wasser und
Salz haben keinen, also fiel ihr Prozentwert auf null, sobald sich die Menge
änderte -- eine Zutat, die der Bäcker mit 62 % eingetragen hatte, stand nach
einer Mengenkorrektur mit 0 % da.

Beim Anlegen zeigte sich das nicht: Odoo rechnet ein explizit geschriebenes
Feld nicht neu. Erst ein Test, der die Menge NACHTRÄGLICH ändert, brachte es
ans Licht.

Nur eine Vorstufe braucht die Umrechnung, weil ihr Prozentwert die versäuerte
Mehlmenge meint und nicht ihre Masse. Jede andere Zeile wird schlicht gegen
die Mehlbasis gewogen.

Eine Vorstufe ganz ohne Mehl -- ein Brühstück aus Altbrot und Wasser -- fällt
bewusst in denselben Fall und wird nach Masse dosiert. Sie kam beim
Vorbereiten der Demodaten ans Licht: das Berliner Roggenmischbrot hat genau so
ein Brühstück.

Dazu das Mehlverhältnis: der Rest auf 100 % verteilt sich jetzt nach dem
Verhältnis der Mehlzeilen zueinander statt zu gleichen Teilen. Der Neudorfer
Kalibriertest führt seine beiden Weizenmehle deshalb getrennt, im
Originalverhältnis 1596 : 283, und trifft die veröffentlichte TA weiterhin.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Zwei vollständige Plötzblog-Rezepte über alle Stufen, erzeugt aus den
Original-Grammangaben, die als Kommentar an jeder Stufe stehen. Sie teilen
sich das Roggenanstellgut und zeigen damit die Sperre und den Ableiten-Knopf
an echten Daten.

Die Demodaten haben zwei Fehler gefunden, die 26 Tests nicht gefunden hatten:

Der VORGABEWERT der Mehlbasis stand noch auf 10 statt 10000. Er stammte aus
der Kilogramm-Zeit; kein Test fiel darüber, weil alle die Basis selbst setzen.
Erst die Demodaten liefen sichtbar falsch, mit 6,1 g Mehl statt 6,1 kg.

Eine Vorstufe OHNE MEHL schmälerte die Mehlbilanz. Der Ausgleich zog den
Prozentwert jeder Vorstufenzeile von der Basis ab, aber ein Brühstück aus
Altbrot und Wasser bringt kein Mehl mit -- sein Prozentwert ist eine
Massedosierung. Die direkten Mehle des Berliner Brots bekamen dadurch 9,39 %
statt 29,04 %. Keiner der Tests hatte eine flourlose Vorstufe.

Dazu der Rezeptbaum als OWL-Widget: alle Stufen ineinander, einklappbar, mit
den Kennzahlen darunter. Die Rechnung liegt vollständig in
mrp.bom.bakery_recipe_tree() und ist damit regulär getestet; das JS zeichnet
nur. Eine spätere Portierung auf OWL 3 berührt sie nicht.

Geprüft ist, dass die Ansichten installieren, das Backend-Bündel baut und
Vorlage, Widget-Registrierung und Komponente enthält -- die Minifizierung
hätte einen JS-Syntaxfehler abgebrochen. NICHT geprüft ist, wie der Baum im
Browser aussieht: es gibt keinen im Pod, Tour-Tests sind ausgeschlossen.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Die Baumansicht ist jetzt in einem echten Browser geprüft: sechs Hoot-Tests,
gestartet über einen HttpCase, der die Suite über ihren Tag filtert statt die
gesamte Odoo-Kernsuite mitzuziehen.

Reaktionszeit ist dabei Prüfgegenstand, nicht Absicht: ein Test zählt die
Serveraufrufe mit und schlägt an, sobald ein Klick auf eine Vorstufe wieder
eine Runde kostet. EIN Aufruf liefert den vollständigen Baum, Klappen ist
danach reiner Zustand im Browser. Nachgeladen wird nur bei Datensatzwechsel
oder nach dem Speichern; ungespeicherte Änderungen werden angezeigt statt bei
jedem Zwischenstand neu gerechnet.

Responsiv: die Einrückung steckt in einer CSS-Variablen statt in einer
Inline-Breite und schrumpft auf schmalen Schirmen, die Einheit hinter der
Menge fällt dort weg, die Tabelle rollt waagerecht statt umzubrechen. Ein Test
prüft die Einrückungstiefe, damit die Verschachtelung nicht still verloren
geht.

Drei Stolpersteine, die im Plan stehen, damit der nächste Hoot-Test sie nicht
wiederholt: describe(name) ohne Rumpf bricht die Suite-Registrierung ab; mrp
setzt auf mail auf, also braucht die Bühne defineMailModels(); und
queryAllTexts liest über innerText und liefert leere Zeichenketten, weil die
Bühne kein Layout rechnet.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Eine Änderung am Prozentwert steht jetzt ohne Wartezeit da: Menge, Mehlbilanz
und alle drei Teigausbeuten werden im Browser nachgezogen. Gespeichert wird
verzögert im Hintergrund, danach holt die Komponente den Baum neu -- die
Zahlen aus dem Server bleiben die gültigen, die Rechnung im Browser ist nur
die schnelle Vorschau darauf.

Die Rekursion über die Stufen wird dafür NICHT ins JS dupliziert. Der Server
liefert je Zeile die bereits aufgelösten Faktoren mit -- pct_factor,
binds_flour, flour_ratio und den Gehalt an Mehl, Wasser, Salz und Feuchte je
Einheit. Damit genügt dem Browser ein flacher Durchgang, und die Fachlogik
bleibt an der einen Stelle, an der sie regulär getestet ist.

Vier neue Hoot-Tests: Menge folgt sofort, eine geänderte Vorstufe verteilt das
Mehl neu, die Teigausbeute zieht mit, und gespeichert wird erst nach der
Verzögerung. Einer davon zählt weiterhin die Serveraufrufe mit.

Der Weg dahin hat einen Fallstrick der Testumgebung freigelegt, der im Plan
steht: ohne installierte Schriftart stirbt der Chrome-Renderer LAUTLOS, sobald
er ein Formularelement zeichnen muss. Das Bild ist ein Lauf, der "Running
test" meldet und dann abbricht, während Odoo nur "Unknown error" ausgibt --
die sechs vorherigen Tests liefen nur deshalb, weil sie kein Eingabefeld
gerendert haben.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
odoo force-pushed odoo/add-mrp-bom-baker-percentage from c6f413a6ab to f46960d5f5 2026-09-22 05:49:51 +00:00 Compare 
mrp_bom_baker_percentage hiess nach seiner Rechenmethode, nicht nach dem, was
es tut. baker_recipe_editor benennt die Sache.

Der Verzeichnisname ist der technische Modulname, damit hängt mehr daran als
ein git mv: die Asset-Pfade im Manifest, der Importpfad im JS-Test, der Name
der OWL-Vorlage und die Befehlszeilen in PLAN.md. Der Anzeigename im Manifest
wird "Baker's Recipe Editor".

Die Testdatenbank musste neu aufgesetzt werden statt aktualisiert: das alte
Modul war dort installiert, und beide nebeneinander definierten dieselben
Felder auf denselben Modellen. 29 Python- und 10 Hoot-Tests laufen unter dem
neuen Namen unverändert durch.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Statt einer wachsenden Sammeldatei: Zutaten, Anstellgute und je ein Rezept pro
Datei. Ein neues Rezept ist damit eine neue Datei statt ein Eingriff in
bestehende.

Die Anstellgute liegen bewusst separat und nicht bei einem der Rezepte. Beide
teilen sich dasselbe Roggenanstellgut, und genau daran hängt die
Vorstufensperre -- in einer der Rezeptdateien wäre diese Beziehung versteckt.

Die Reihenfolge im Manifest trägt jetzt einen Kommentar, weil sie tragend ist:
eine Datei darf nur auf Datensätze verweisen, die eine vorher geladene angelegt
hat.

Nachgemessen an der neu aufgesetzten Demo-Datenbank: unveränderte Zahlen,
Neudorfer Brutto-TA 169,58 gegen die angegebenen 170, Berliner 10000 g Mehl
und Mehle je 29,04 %, Anstellgut in zwei Rezepturen und damit gesperrt.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Code, Kommentare, Docstrings, Feldbeschriftungen, Hilfetexte, Ansichten,
Tests, Demodaten und PLAN.md sind englisch. Deutsch bleibt nur, wo es
Eigenname ist: die beiden Brotnamen (Berliner Roggenmischbrot, Neudorfer
Sauerteigbrot Nr. 1) und die Quellenangaben.

Die Fachbegriffe folgen dem englischen Backhandwerk statt einer wörtlichen
Übersetzung: Vorstufe wird preferment, Brühstück wird scald (nicht soaker,
das wäre ein Quellstück), Teigausbeute wird dough yield, Teigeinlage wird
dough weight, versäuerte Mehlmenge wird prefermented flour -- das deckt auch
den Vorteig ab und nicht nur den Sauerteig.

i18n/de.po ist nicht von Hand geschrieben, sondern aus "odoo-bin i18n export"
erzeugt und dann gefüllt. Das war die Mühe wert: der Export findet auch die
Texte aus der OWL-Vorlage, die ich sonst übersehen hätte. Sechs Terme sind
bewusst nicht enthalten -- Bill of Material, Companies, Display Name, ID,
Product -- die tauchen nur durch die Vererbung auf und übersetzt Odoo selbst.

Nachgeprüft an einer Datenbank mit geladener Sprache: die Beschriftungen
kommen auf Deutsch heraus, einschließlich der Auswahlwerte von bakery_type.
29 Python- und 10 Hoot-Tests unverändert grün.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Im Browser nachgestellt, nicht geraten. Drei Befunde, alle aus echter
Benutzung gemeldet:

Tippen war unmöglich. Das Prozentfeld wurde bei jedem Anschlag mit toFixed(2)
neu gezeichnet: aus "2" wurde sofort "2.00", die nächste Ziffer fiel weg.
Solange ein Feld den Fokus hat, zeigt es jetzt genau das Getippte; die
formatierte Anzeige kommt zurück, sobald man es verlässt. Alles Abgeleitete
rechnet weiter bei jedem Anschlag mit. Kein Test hatte das gefunden, weil alle
Werte über das Modell setzten statt über die Tastatur -- der neue tippt
zeichenweise und prüft den Feldinhalt selbst.

Die Teigausbeute bewegte das Wasser erst beim Speichern. Die Inverse eines
nicht gespeicherten Compute-Felds läuft zur Schreibzeit; von aussen sieht das
aus, als passiere nichts. Im Baum ist die TA jetzt ein Eingabefeld, das die
Wasserzeile sofort nachzieht, und im Formular greift ein onchange. Die Inverse
zweimal aufzurufen schadet nicht, sie rechnet ein absolutes Ziel statt einer
Differenz.

Nicht beschreibbare Zeilen waren eine Sackgasse. Mehlzeilen und Unterstufen
tragen bewusst kein Eingabefeld -- aus Benutzersicht sind das aber 11 von 15
Zeilen ohne erkennbaren Grund. Öffnen und Ableiten gab es nur in der Liste,
nie im Baum; jetzt hängen sie an den Vorstufenzeilen, auf jeder Ebene, und die
gesperrten Zellen tragen einen Hinweis, warum sie es sind.

Ein halb getippter Wert kam als NaN durch die Bereichsprüfung, weil jeder
Vergleich mit NaN falsch ist. Unfertige Eingaben tun jetzt schlicht nichts.

30 Python- und 15 Hoot-Tests grün, im Browser gegengeprüft: Tippen ergibt
3 / 35 / 355, TA 230 setzt das Wasser sofort auf 5867,3 g.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
odoo force-pushed odoo/add-mrp-bom-baker-percentage from da05b81100 to 3305bb8933 2026-09-22 17:51:00 +00:00 Compare
odoo force-pushed odoo/add-mrp-bom-baker-percentage from 3305bb8933 to aca0120c91 2026-09-22 18:31:34 +00:00 Compare
odoo force-pushed odoo/add-mrp-bom-baker-percentage from aca0120c91 to 0306bb107f 2026-09-22 18:47:42 +00:00 Compare
odoo force-pushed odoo/add-mrp-bom-baker-percentage from 0306bb107f to 41e767a465 2026-09-22 19:02:17 +00:00 Compare
odoo force-pushed odoo/add-mrp-bom-baker-percentage from 41e767a465 to 04fdc36b69 2026-09-22 19:04:18 +00:00 Compare
odoo force-pushed odoo/add-mrp-bom-baker-percentage from 04fdc36b69 to 1d7edb73c4 2026-09-22 19:40:59 +00:00 Compare
odoo force-pushed odoo/add-mrp-bom-baker-percentage from 1d7edb73c4 to f3cd9b3f60 2026-09-22 19:46:22 +00:00 Compare
odoo force-pushed odoo/add-mrp-bom-baker-percentage from f3cd9b3f60 to c63964f480 2026-09-22 20:54:30 +00:00 Compare
odoo force-pushed odoo/add-mrp-bom-baker-percentage from c63964f480 to 7104984a8a 2026-09-23 16:53:55 +00:00 Compare
odoo force-pushed odoo/add-mrp-bom-baker-percentage from 7104984a8a to 8c60e12e64 2026-09-23 17:04:28 +00:00 Compare
odoo force-pushed odoo/add-mrp-bom-baker-percentage from 8c60e12e64 to 223e82871d 2026-09-23 18:08:15 +00:00 Compare
odoo force-pushed odoo/add-mrp-bom-baker-percentage from 223e82871d to 45b509201d 2026-09-23 19:19:30 +00:00 Compare 
Beide sind Zubereitungen, und sie werden verschieden gebraucht: ein
Anstellgut wird geführt und geht als Zutat in eine Stufe ein, eine Vorstufe
wird für ein Rezept angesetzt und ist eine eigene Stufe. Ohne diesen
Unterschied kann das Formelblatt nicht entscheiden, was beim Einlesen zur
Stufe wird und was Zutat bleibt.

Mit der Sauerkeit hat das nichts zu tun: die trägt das Anstellgut, und ein
Sauerteig wird daran erkannt. Ein Hefevorteig ist eine Vorstufe ohne Säure,
ein Weizenanstellgut ein Anstellgut mit.

Die fünf Presets und das Demo-Anstellgut sind entsprechend markiert.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This pull request can be merged automatically.
This branch is out-of-date with the base branch
You are not authorized to merge this pull request.
View command line instructions

Checkout

From your project repository, check out a new branch and test the changes.
git fetch -u origin +refs/pull/1/head:odoo/add-mrp-bom-baker-percentage
git switch odoo/add-mrp-bom-baker-percentage

Merge

Merge the changes and update on Forgejo.

Warning: The "Autodetect manual merge" setting is not enabled for this repository, you will have to mark this pull request as manually merged afterwards.

git switch 19.0
git merge --no-ff odoo/add-mrp-bom-baker-percentage
git switch odoo/add-mrp-bom-baker-percentage
git rebase 19.0
git switch 19.0
git merge --ff-only odoo/add-mrp-bom-baker-percentage
git switch odoo/add-mrp-bom-baker-percentage
git rebase 19.0
git switch 19.0
git merge --no-ff odoo/add-mrp-bom-baker-percentage
git switch 19.0
git merge --squash odoo/add-mrp-bom-baker-percentage
git switch 19.0
git merge --ff-only odoo/add-mrp-bom-baker-percentage
git switch 19.0
git merge odoo/add-mrp-bom-baker-percentage
git push origin 19.0
Sign in to join this conversation.
Reviewers
No reviewers
Labels
Clear labels
No items
No labels
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
odoo/odooapps!1
No description provided.