Zum Inhalt

1:1-Spiegel aus dem Repo

Quelle: planning/PLAN_EINTAUSCH_MULTIMODELL.md · Stand der Quelldatei: 10.08.2026 21:59 · erzeugt: 14.08.2026 00:33 Diese Seite ist eine wortgetreue Kopie. Geaendert wird immer die Quelldatei, nie diese Seite.

PLANUNG · Neuentwicklung "eintauschaktion-mehr-modell" — Multimodell + Express-Pfad + Erinnerungen

Status: REINE PLANUNG (M, 09.08.2026) — kein Bau, keine Aenderung am laufenden Prozess. Grundlage: dokumentierter IST-Stand aus Betrieb + Skills; alles nicht hart Belegte ist als [OFFEN-V*] Verifikations-Read markiert und wird VOR dem Bau gelesen.

1. IST-Ablauf Ende-zu-Ende (wie die Aktion heute laeuft)

  1. Formular/Sheet: Kunde fuellt das Eintausch-Formular; Google-Apps-Script (automation_version 0.6.3, deployt M) erzeugt einen HMAC-Code (Muster 868G-XXXX-XXXX-XXX, hmac-human-v2) und den Ticket-Payload w6.tradein.ticket.v1 mit model (z. B. W-NM-868) und source_sheet (z. B. "Grundmodell") → Mail an den Helpdesk → Odoo-Ticket (Team 1, Eingangs-Stufe). Beleg: Ticket-6295-Payload.
  2. Kundenmail #1 (Bestaetigung/Code): kommt aus der Script-Strecke [OFFEN-V1: exakter Versandweg + Vorlage].
  3. EIA Stufe-1-Scan (n8n, alle 15 min, Cursor id>last): Envelope parsen, klassifizieren, Partner zuordnen/anlegen, Angebots-ENTWURF mit festem Aktionsartikel/-preis (Grundmodell 399 EUR; Leitplanken D-043: genau 1 Entwurf, draft, 0<Betrag≤500, je Partner/Palette einmal).
  4. Ankunft der Maschine: Mitarbeiter schiebt Ticket auf Stufe 40 "Eintauschaktion" → EIA zieht Palettenplatz und versendet das Angebot automatisch (Stufe 3; Kundenmail #2 via Odoo mail.template aus der Allowlist). Garantie-Anhaenge haengen an base.automation 22/24.
  5. Sicherheitsnetz: ICP-Schalter w6.eia.enabled (Not-Aus), Board-Logging jedes Laufs, Dedupe, kill_switch-Block bewiesen.

WICHTIG (M, 09.08.): Die Aktion kennt HEUTE bereits zwei Varianten — W-NM-868 und W-NM-868-S. Wie 868-S aktuell abgebildet ist (eigener Reiter? offer_type im selben Reiter "Grundmodell"? eigenes Code-Praefix 868S-? eigener Preis/Artikel im EIA?), ist der wichtigste Verifikationspunkt [OFFEN-V7] — der Umstieg nutzt BEIDE als Erstbestueckung.

Die zwei modellabhaengigen Stellen sind damit: (A) Script-Strecke (Reiter → Code-Praefix → Kundenmail #1) und (B) EIA (model → Odoo-Artikel + Preis + Mail-Vorlage #2). Genau dort setzt die Erweiterung an — sonst nirgends.

2. Bewertung der Reiter-Idee: JA, richtig — mit einer Ergaenzung

Reiter je Modell (W-NM-868, W-NM-868-S, …) ist die richtige M-Pflegestruktur: Der Payload traegt source_sheet/model BEREITS — die Architektur ist darauf vorbereitet, neue Reiter sind neue Werte, kein Umbau der Ticket-Strecke. Reiter-Name = interne Referenz = model-Wert: EINE Systematik ueberall (Sheet, Code-Praefix, Ticket, Angebot, Auswertung).

Ergaenzung (der eigentliche Planungskern): Ein Mapping als EINE Wahrheit. Nicht "der Agent weiss die Preise", sondern eine Konfig-Tabelle MODELL-MAPPING mit je Zeile: referenz (Reiter) · aktiv j/n · odoo_produkt_id · angebotspreis · mail_baustein/template_ref · code_praefix · bemerkung. Vorschlag Doppelhaltung mit klarer Rollenteilung: Pflegeort = _CONFIG-Reiter im selben Spreadsheet (M pflegt alles an einem Ort, Script liest ihn direkt) · Wirkort fuer EIA = Supabase agent_config (Board-sichtbar, auditierbar per gov_act, D-050) · ein kleiner Sync prueft beide gegeneinander und alarmiert bei Drift (Muster Struktur-Soll/Drift-Check). Unbekanntes model im Ticket → KEIN Angebot, Route "Vorgang unklar" + P1-Alarm — nie raten, nie Standardpreis.

Mail-Empfehlung: EINE Vorlage je Mail-Typ mit Modell-PLATZHALTERN ({{model}}, {{preis}}, {{textbaustein}}) statt je Modell eine eigene Vorlage — weniger Template-Wildwuchs, ein Freigabeweg; eigene Vorlage nur, wenn ein Modell inhaltlich WIRKLICH anders spricht. [M-Entscheid E]

3. Upgrade OHNE Stoerung — Phasenplan (jede Phase einzeln rueckrollbar)

Phase 0 · Verifikations-Lesepaket (read-only, vor jedem Bau): [V1] Apps-Script-Code (0.6.3): Reiter-Handling, Code-Erzeugung, Mail-Versandweg #1 · [V2] EIA-v0.4 exakt: wo stehen Artikel/Preis/Template hart — und unterscheidet er 868/868-S schon? · [V3] Sheet-Struktur live (alle Reiter + Spalten) · [V4] Odoo: Aktionsartikel + mail.templates je Variante · [V5] Code-Praefix-Logik (868G vs. 868S? Kollisionsfreiheit) · [V6] Palettenplatz-Logik (global/je Modell) · [V7] Wie laeuft W-NM-868-S HEUTE durch alle 5 Ablauf-Schritte (der Referenzfall fuer den Cutover).

Phase 1 · Multimodell-Fundament MIT den zwei realen Varianten (M-Wunsch 09.08.): _CONFIG-Reiter + agent_config werden direkt mit ZWEI Zeilen erstbestueckt — W-NM-868 und W-NM-868-S, Werte 1:1 aus dem V-Paket (heutige Artikel/Preise/Mails, KEINE inhaltliche Aenderung). Script v0.7 und EIA v0.5 lesen das Mapping statt Hartwerten, verstehen uebergangsweise ALT UND NEU (alter Reiter/offer_type bleibt lesbar — Parallelbetrieb statt Umbau im Flug). Beweis: Trockenlauf-Diff je Variante — ein 868- und ein 868-S-Testfall muessen byteident zu heute herauskommen (Entwurf, Preis, Mailtext). Rollback: n8n-Version zurueck, Script-Version zurueck, Mapping unbenutzt. Phase 2 · Cutover der Reiter-Systematik im Schatten: Neue Reiter W-NM-868 und W-NM-868-S (Reiter-Name = Referenz) parallel zum Alt-Reiter anlegen, Formular-Ziel NOCH NICHT umgestellt; M macht je Variante eine Testeinreichung ueber die neuen Reiter → Ticket → EIA-ENTWURF → M prueft Entwurf + beide Mails. Alt-Strecke laeuft waehrenddessen unveraendert weiter. Phase 3 · Umschalten (M-Schalter): Formular/Links auf die neuen Reiter; Alt-Reiter wird EINGEFROREN (schreibgeschuetzt, nicht geloescht — Rueckweg + Historie). Ab hier ist die Aktion multimodell-nativ mit den zwei Bestandsvarianten. Phase 4 · Jedes weitere Modell = eine Zeile + ein Test: _CONFIG-Zeile (Referenz, Artikel, Preis, Baustein, Praefix) → Schatten-Testeinreichung → M-Abnahme → aktiv. Kein Codeeingriff mehr noetig — das ist der Skalierungsgewinn.

Stoerungsfrei-Garantien: Alt-Reiter/Codes/Cursor/laufende Tickets bleiben in Phase 0-2 unberuehrt (Parallelbetrieb); die einzige Umschaltung (Phase 3) ist ein M-Klick mit sofortigem Rueckweg (Formular-Ziel zurueckstellen); kundenwirksame Publishes wie immer M; Deckel/Dedupe/Not-Aus unveraendert.

4. Risiken-Register (Planung)

Risiko Gegenmittel
Falsches Template/Preis je Modell Mapping-EINE-Wahrheit + Pflicht-Testdurchlauf je Modell mit M-Mail vor Scharfschaltung
Unbekanntes/vertipptes model im Payload Unklar-Route + Alarm statt Default
Reiter umbenannt/geloescht (Mitarbeiter) _CONFIG-Soll + Drift-Alarm im Script (Lockdown-Muster)
Code-Praefix-Kollision V5 vorab; Praefix-Spalte im Mapping ist die einzige Quelle
Angebot > 500 EUR (Deckel D-043) [M-Entscheid C] BEVOR ein teureres Modell aktiv wird — Deckel ist Policy, kein Code
Paletten-Vermischung zwischen Modellen V6; ggf. Palettenkreis je Modell als Mapping-Spalte
Doppel-Entwuerfe beim Umstellen Phase-1-Diff-Beweis + bestehende Dedupe-Leitplanken

5. M-Entscheide fuer diese Planung (vor Phase 0 nichts noetig, vor Phase 1 bitte A-C)

  • A Referenz-Systematik bestaetigt? (Reiter-Name = interne Referenz = model; Konvention W-NM-<nnn>[-S|…])
  • B ENTSCHIEDEN (M 09.08.): Preise/Artikel = das, was in Odoo ist; M liefert die Modell-Liste.
  • D ENTSCHIEDEN (M 09.08.): ALLES kommt auf EINE Palette (ein gemeinsamer Kreis).
  • ~~B alt~~ Bestaetigung der Erstbestueckung: heutige Werte fuer W-NM-868 UND W-NM-868-S (Preis/Artikel/Mailtext) gelten unveraendert als die zwei ersten Mapping-Zeilen; dazu ggf. schon die naechsten geplanten Modelle
  • C Falls ein Preis > 500 EUR: Deckel-Anhebung je Modell ja/nein (Policy-Entscheid)
  • D Paletten: ein gemeinsamer Kreis oder je Modell getrennt?
  • E Mail: eine Vorlage mit Platzhaltern (Empfehlung) oder je Modell eigene?

Naechster Schritt nach M-Ok zur Planung: Phase-0-Lesepaket als Auftrag schneiden (G-READ + T-Lane fuer Script-Lektuere) — weiterhin ohne jede Aenderung am laufenden Betrieb.

TEIL 2 · Express-Pfad "Ich will nicht warten!" + Erinnerungen (M, 09.08.2026 — reine Planung)

6. Der Express-Pfad (neuer, SCHALTBARER Zweig — eigener Toggle, an/aus jederzeit)

Kundenerlebnis: In der Code-Mail (#1) erscheint unten ein Knopf "Ich will nicht warten!" → neues Google Form (Express-Formular): (1) Verzicht auf Ruecksendung + Haftungsfreistellung, (2) Erklaerung des Ablaufs (Maschine wird nicht fuer Rueckgabe eingelagert, sondern geht direkt in den Verwertungs-/Recyclingprozess — Platzersparnis), (3) Eingabe Sendungsnummer + Foto-Upload des Einlieferbelegs, (4) Bestaetigung der Bedingungen → SOFORT-Angebot ohne Warten auf den Wareneingang.

Der Deal, kundenklar formuliert (unser Entgegenkommen): Der Kunde bekommt sein Angebot SOFORT statt nach Eingang und Pruefung; im Gegenzug ist der Angebotspreis FINAL — es gibt kein zweites/korrigiertes Angebot nach Ankunft, und die Maschine geht ohne Einlagerung in die Verwertung. Intern aendert sich am Werkstatt-Ablauf NICHTS (Palette wie bisher, D-Entscheid: eine Palette fuer alles) — es entfaellt nur die zweite Angebotsschleife.

Technik-Skizze: Knopf-Link traegt den HMAC-Code (Vorbefuellung, kein Tippfehler-Risiko) → Express-Form-Submission → Verarbeitung (Script/Flow): Ticket um Express-Flag + Sendungsnr + Beleg-Referenz ergaenzen → Sofort-Trigger fuer EIA statt 15-min-Polling [OFFEN-V8: Trigger-Weg — Form-Submit-Webhook an n8n (echte Sofortigkeit) vs. verkuerzter Cursor-Lauf; Praeferenz Webhook, Entscheidung nach V-Paket] → EIA baut/versendet das Angebot auf dem bestehenden, bewaehrten Weg (Leitplanken D-043 unveraendert: Deckel, 1 Entwurf, Dedupe; Express aendert TIMING, nie Limits). Palettenplatz wird wie bei Ankunft gezogen, sobald die Maschine real eintrifft — Werkstattprozess identisch.

7. Marketing-Einwilligung + Opt-out-Log (Voraussetzung fuer jede Erinnerung)

Footer der Code-Mail: Teilnahmehinweis, dass zur Aktion gehoerende Status-/Erinnerungs-Mails versendet werden; Widerspruch jederzeit per Klick. Widerspruchs-Klick → kleiner Handler → Opt-out-Log in unserer Tabelle (wer, wann, Quelle) → JEDER Erinnerungs-Versand prueft VORHER das Log (Gate im Flow, nicht guter Wille). Ohne funktionierendes Opt-out-Log geht KEINE Erinnerung live.

8. Erinnerungs-Engine (eigener Flow "EIA-REMIND", eigener Schalter, Stufenmodell)

Logik: R1 = Angebotsdatum + 3 Tage, mittags (~12:00) · R2 = am ersten SONNTAG nach Angebotsdatum + 5 Tagen, abends (~09:00) (Ms Vorgabe "3 Tage mittags, 5 Tage am Wochenende/Sonntag" als Regel gefasst). Startheuristik Versandzeiten aus allgemeiner B2C-Erfahrung (Mittag + Sonntagabend sind starke Lesefenster) — und ab Betrieb DATENGETRIEBEN nachgeschaerft: wir messen Annahme-/Antwortquote je Versandfenster in der Aktions-Tabelle und justieren die Zeiten nach 4-6 Wochen (kein Tracking-Pixel noetig — gemessen wird am Verhalten: Annahme/Antwort/Anlieferung). Stopp-Bedingungen (Pflicht-Gates vor jedem Versand): Angebot angenommen/bezahlt · Maschine eingetroffen · Ticket geschlossen/Widerruf · Opt-out im Log · Express-Fall bereits versendet+beantwortet. Max 2 Erinnerungen, danach Schluss.

9. Rechts-/Formulierungspunkte — M klaert (ggf. Anwalt); G liefert Textentwuerfe, KEIN Urteil

  • R-1 Recycling-Formulierung: Kundentext muss WAHR sein. Vorschlag: "Ihre Maschine wird nicht fuer eine Rueckgabe aufbewahrt; mit Ihrer Bestaetigung geht sie unmittelbar in unseren Verwertungs-/Recyclingprozess." (Das ist korrekt: Palette = Beginn der Verwertung, keine Ruecksendung, kein Zweitangebot. Die Formulierung "wird sofort entsorgt" waere angreifbar, weil intern zeitversetzt — nicht verwenden.)
  • R-2 Haftungsfreistellung/Preisbindung per Formular: Wirksamkeit + noetige Checkboxen/Textbausteine (finaler Preis, Verzicht auf Rueckgabe) — juristisch pruefen lassen.
  • R-3 Erinnerungs-Mails: Zulaessigkeitsbasis (Einwilligung im Rahmen der Aktionsteilnahme vs. Bestandskundenregel), Footer-Text, Widerrufsbelehrung — pruefen lassen; Opt-out-Log ist technisch eingeplant (§7).
  • R-4 Beleg-Foto-Upload: personenbezogene Daten im Upload (Adresse auf Beleg) → Aufbewahrungs-/Loeschregel in die Aktions-Tabelle aufnehmen.

10. Arbeitspakete (je: schaltbar · abends getestet · 100% Rollback · Betrieb unberuehrt)

AP Inhalt Abhaengig von Rollback Test (abends, nie echte Kunden)
AP0 Verifikations-Reads V1-V8 Script, EIA, Sheet, Templates, Praefixe, Paletten, 868-S-Weg, Trigger-Optionen — n.a. (read-only) n.a.
AP1 Multimodell-Fundament _CONFIG+agent_config (2 Zeilen aus Odoo-Werten), Script v0.7, EIA v0.5 AP0, M-Liste (B) n8n-/Script-Version zurueck, Mapping ungenutzt Trockenlauf-Diff je Variante byteident
AP2 Reiter-Cutover neue Referenz-Reiter parallel, M-Testeinreichungen, Formular-Umschaltung (M) AP1 Formular-Ziel zurueckstellen; Alt-Reiter eingefroren Schatten-Einreichung je Variante
AP3 Express-Pfad Knopf (Toggle!), Express-Form, Verarbeitung, Sofort-Trigger, Sofort-Versand AP1 (Mapping), R-1/R-2-Texte Toggle aus = Knopf weg, Verhalten exakt wie heute Testcode + Test-Submission an M-Mail, Ende-zu-Ende im DEV
AP4 Einwilligung + Opt-out-Log Footer, Widerspruchs-Handler, Log-Tabelle, Versand-Gate R-3-Text Footer-Revert; Log bleibt (append-only) Klick-Test M, Log-Eintrag verifiziert
AP5 Erinnerungs-Engine EIA-REMIND-Flow (R1/R2-Logik, Stopp-Gates, eigener Schalter) AP4 zwingend Schalter aus; Flow unpublished Trockenlauf: Digest "wuerde heute erinnern an…" 3 Tage lang, dann M-Freigabe

Reihenfolge: AP0 → AP1 → AP2; danach AP3 und AP4 parallel moeglich; AP5 NUR nach AP4. Jedes AP endet mit Gate + M-Abnahme; Tests im Abendfenster (nach 19:00), alle neuen Flows als [DEV] mit eigenem Schalter im D-050-Regime (Registry, Board, Not-Aus), Publish kundenwirksamer Teile wie immer durch M.

11. Noch offene M-Punkte fuer Teil 2

  • Modell-Liste aus Odoo (B — M liefert) · A/C/E aus Teil 1 unveraendert offen
  • R-1 bis R-4 Texte/Freigaben (G liefert Entwuerfe auf Zuruf)
  • V8-Entscheid Sofort-Trigger (nach AP0)
  • Wortlaut des Knopfs ("Ich will nicht warten!") und des Entgegenkommens-Textes — G entwirft, M entscheidet

§12 ENTSCHEIDE 2026-08-09 — Freigabe Teil 2 durch M (D-065); gilt, wo abweichend, vor §6–§11

  • V8 ENTSCHIEDEN — Webhook-Sofort-Trigger. M: „sofort, ist sofort: der kunde ist jetzt bereit zu kaufen." Kein 15-min-Polling fuer Express. Umsetzung in AP3: eigener n8n-Flow [EXPRESS] mit Webhook-Trigger. Absicherung: (a) Express-Form-Apps-Script postet bei Submit mit Shared-Secret-Header (Wert nur in n8n-Variables, D-017), (b) HMAC-Code-Pruefung hmac-human-v2 gegen den mitgesendeten Code, (c) Dedupe je Code — Doppel-Submit erzeugt kein zweites Angebot, (d) D-043-Leitplanken unveraendert (1 Entwurf, draft, 0<x<=500, Partner, Palette), (e) eigener Schalter EXPRESS_AN.
  • R-1 ok — Kundentext wie vorgeschlagen: „Ihre Maschine wird nicht fuer eine Rueckgabe aufbewahrt; mit Ihrer Bestaetigung geht sie unmittelbar in unseren Verwertungs-/Recyclingprozess."
  • R-2 ok — Checkbox-Wortlaute vor Livegang mit Rechtsblick.
  • R-3 ok, ERWEITERT — Speicherort Odoo. M: „das muss gespeichert werden, am besten in odoo, dafuer gibt es schon infos, er kann sich dann selbst drueber auch abmelden." Einwilligung/Widerspruch wird in Odoo gefuehrt (Bordmittel Sperrliste/Selbstabmeldung — welcher Bestand bei uns aktiv/installiert ist, erhebt AP0 lesend als Baustein V9; keine Annahme ohne Beleg, D-020). Google-Tabelle bleibt Spiegel/Arbeitssicht. Das Versand-Gate (Par.7) prueft vor jeder Erinnerung gegen Odoo.
  • R-4 ok — Stopp-Gates unveraendert.
  • Par.8 GEAENDERT — R2-Erinnerung 09:00 morgens. M: „Sonntag nach Tag+5, 09:00 also es muss morgens kommen." R1 bleibt T+3 12:00. „Klueger machen" bestaetigt: je Erinnerung Sendezeit x Annahme loggen, nach einigen Wochen datengetrieben nachstellen.
  • AP-Anpassungen: AP0 + V9 (Odoo-Opt-out-Bestand, read-only) · AP3 inkl. Webhook-Flow wie oben · AP4 = Einwilligung/Selbstabmeldung in Odoo + Versand-Gate. Reihenfolge unveraendert: AP0→AP1→AP2, dann AP3 parallel AP4, AP5 nur nach AP4.
  • Offen bleibt: Modell-Liste mit Angebotspreisen aus Odoo (B, M liefert) · Wortlaute Knopf/Entgegenkommen/Checkboxen (Einzelfreigabe vor Livegang) · Rechtsblick R-2 · Startfreigabe AP0.

Par.13 KONZEPT-OPTIMIERUNG Bedienung/Schalter (09.08. 20:42, aus M-Konzept + gelieferter Modell-Liste)

M-Konzept (Chat 09.08.): Reiter je interner Referenz · Jotform laeuft ins Sheet · Modelle per Apps-Script-Menue an/aus (aktuell an: W-NM-868 + W-NM-868-S) · Alternativen von M angeboten: Odoo-Systemvariablen ODER Board-Agentenkarten mit "mehr Optionen".

G-Empfehlung — EIN Schreiber, gerichteter Fluss: 1. WAHRHEIT: agent_config (Supabase) — models{} je Referenz: active, odoo_product_id, preis_feld, palette, textbaustein_key, cap. n8n/EIA liest sie heute schon (RPC w6a_agent_config vorhanden). 2. BEDIENUNG: Board (Ms Favorit) — EIA-Karte → Panel "Modelle": Toggle je Referenz → RPC mit gov_actions-Audit → agent_config. Hierarchie bleibt: Not-Aus w6.eia.enabled schlaegt ALLE Modell-Toggles. T5-Zuarbeit (Runde nach R9) = NEU AP6 (nicht blockierend: bis das Panel steht, schaltet M per Zuruf an G, G aendert agent_config auf Einzelauftrag mit Vorher/Nachher-Beleg). 3. VERTEILUNG (gerichtet): n8n spiegelt die aktive Modell-Liste in den _CONFIG-Reiter des Sheets (Anzeige fuer M + Apps Script) und Stufe 2 in die Jotform-Feldoptionen (Jotform-API; MCP verbunden — AP0 kann das Formular direkt lesen). Apps-Script-Menue = ANZEIGE + "Sync pruefen", KEIN zweiter Schreibort (ein Pfad = ein Schreiber gilt auch fuer Config). 4. ODOO-Systemvariablen als Modell-Schalter: NEIN. Gruende: (a) D-054 — die Kundenseite (Apps Script/Jotform) darf Odoo nie lesen, die Wahrheit laege fuer die halbe Kette unerreichbar; (b) Editor-UI fehleranfaellig fuer Referenz-Listen. Odoo bleibt Wahrheit fuer Preis/Artikel + globalen Not-Aus. 5. NETZ (unveraendert Kern): Payload-Modell unbekannt ODER inaktiv → Unklar-Route + Alarm, nie Default. Anzeige-Sync darf ausnahmsweise stale sein — die ANGEBOTS-Entscheidung nie. Jotform-Eingang landet in EINEM Eingangs-Reiter; Modell steht in der Payload (model/source_sheet); Modell-Reiter = menschliche Ablage/Sicht, NICHT Entscheidungsquelle.

Befunde aus der Modell-Liste (Ablage: zulieferung/eintausch-mehr-modell/MODELL_LISTE_ODOO_2026-08-09.csv): - 45 Zeilen: 44 Maschinen-Varianten + W-Z-STICK-EU7 (Stickeinheit). Muster Grundmodell/-S ("Schnaeppchen") durchgaengig — der 868/868-S-Mechanismus skaliert 1:1. - 4 Referenzen mit haengendem Bindestrich (= "mit Stickeinheit EU7 und Software"): W-NM-3300-PRO-EU7-, W-NM-5000-EXKL-EU7-, W-NM-5000-PRO-EU7-, W-NM-8000-EXKL-EU7- → VOR Aktivierung in Odoo bereinigen (z.B. ...-EU7-SW); Verwechslungsgefahr mit ...-EU7 im Mapping/Reiternamen. - Liste enthaelt KEINE Preise → korrekt nach Entscheid B: Agent liest live aus Odoo. WELCHES Preisfeld je Modell gilt (Listenpreis vs. Aktionspreis), klaert AP0 — Beleg fuer den Bedarf: 868-S-Drift 549 (Liste) / 499 (Aktions-Soll im Flow-Check) / 349 (gebauter Preis). - Bundles (EU7 / EU7+Software) + Stickeinheit einzeln schaltbar wie jede Referenz. Teure Modelle (5000er/8000er/9500er) liegen absehbar ueber dem D-043-Deckel 500 EUR → Entscheid C VOR deren Aktivierung; Vorschlag: cap je Modell ins Mapping, globaler Hoechstdeckel bleibt als zweites Netz.

AP-Anpassung: AP1 = Mapping in agent_config + _CONFIG-Spiegel (statt Sheet als Wirkort) · NEU AP6 = Board-Modell-Panel (T5, nach R9; optional, nicht blockierend) · Jotform-Feld-Sync = Stufe 2 in AP3. Reihenfolge AP0→1→2, 3 parallel 4, 5 nach 4 unveraendert.

Par.14 SCOPE-FIXIERUNG (M, 09.08. abends — D-066) + AP0 Runde 1

  1. Baubereich: AB Google-Sheet BIS Odoo (Sheet-Struktur, _CONFIG-Spiegel, Apps-Script-Spezifikation [Deploy: M], Mail-Vorlagen, Odoo-Gateway, EIA/[DEV]-Flows, Board-Panel AP6).
  2. Jotform = ausschliesslich M. Wird je Aktion von M aufgesetzt und laeuft in DIESELBE Tabelle. Wir bereiten vor: _CONFIG/Mapping als Ablese-Vorlage (welche Modelle an, welche Felder das Formular braucht). Par.13-Punkt "Jotform-Feldoptionen via API" GESTRICHEN. AP0-R1 hat das Jotform-Konto NUR inventarisiert (2 aktive 868-Formulare + N-8000-Vorlaeufer), nichts veraendert.
  3. Anwendung auf 868 + 868-S: die laufende Aktion wird auf die modulare Struktur migriert (AP1/AP2 unveraendert; Trockenlauf-Diff byteident bleibt das Gate).
  4. Modus: reine Planung — KEIN Code bis Ms Baufreigabe. AP0-R1-Befunde (read-only Bestandsaufnahme): zulieferung/eintausch-mehr-modell/AP0_BEFUNDE_RUNDE1.md. Kernantworten: Mail-Kette laeuft (Beleg 09.08. 17:28, Script 0.6.3, zwei Mails je Zeile: Kundencode + Werkstatt/Ticket-Payload an Odoo-Gateway); Code-Mail bereits weitgehend modellneutral → Entscheid E: EINE Vorlage mit Platzhaltern ({{model}}, {{preis}}, {{gattung}}, {{textbaustein}}) traegt alle 45 Referenzen; agent_config ohne models{} (AP1); EIN Sheet fuehrt beide Varianten.
  5. Einordnung Gesamtkonzept: Strang 7 im ROLLING_PLAN · Prioritaet NACH Odoo-Core (B3/B4) · Ausfuehrung bei Freigabe: G ([DEV]-Flows, Config, Spezifikationen) + T5 (AP6 Board-Modell-Panel nach R9) + M (Script-Deploy, Jotform je Aktion, Wortlaut-Einzelfreigaben, Umschaltung) · Testfenster abends, jedes AP einzeln rueckrollbar (Par.10/12) · Sichtbarkeit: Strang 7 erscheint automatisch auf der mkdocs-Live-Site (T6).

§15 — Gratisprodukt & Preis modular (M-Auftrag 10.08., nur Pruefung/Entwicklung, KEIN Bau)

Ist (belegt EIA v0.4)

Gratis-Beigabe (868/868-S: Garn W-G-0015, 4 Rollen, 0 EUR), Maschinenpreise (399/349) und Schnaeppchen-Erkennung sind HART im Agenten an 3 Stellen: "Produkte laden" (default_code), "Angebot bauen" (PREISE + order_line), "Reparatur-Plan" (GARN_ID/MACH_ID). Schnaeppchen kommt heute NUR aus dem Ticket-offer_type (Sheet/Jotform).

Soll: zentrale Wahrheit in agent_config (Supabase), Bedienung Board, Anzeige Sheet _CONFIG (= D-013-Schalterkonzept, erweitert)

agent_config.models[] = { aktiv: bool, preis: number, // Maschinen-Aktionspreis gratis: [ {ref: "W-G-0015", menge: 4} ], // LISTE -> mehrere/andere Beigaben modular; price_unit immer 0 schnaeppchen: bool // steuert Schnaeppchen-Variante zentral (statt nur offer_type) } Agent liest zur Laufzeit statt harter PREISE/GARN. order_line wird dynamisch aus gratis[] gebaut.

Warum agent_config (nicht Odoo-Param / nicht Sheet als Wahrheit)

Schalter-Wahrheit liegt bereits in agent_config (D-013) -> zwei Wahrheiten = Divergenzrisiko. Sheet = Anzeige/Bedienung, DB = atomar lesbar. Odoo-Param moeglich, aber verteilt die Wahrheit.

Schnaeppchen "ausmachen"

schnaeppchen-Flag je Modell in agent_config; Agent prueft es ZUSAETZLICH zum Ticket-offer_type. So kann M Schnaeppchen je Modell zentral an/aus.

Aufwand (Schaetzung, nach Baufreigabe): 3 EIA-Nodes auf agent_config umstellen + Schema in agent_config + Board-Reiter (T5) + Sheet _CONFIG (Apps Script). KEIN Odoo-ICP je Modell.

§16 AUFTEILUNG/VORZIEHEN (M-Auftrag 10.08. abends, D-073) — Gratis-Wechsel + Paletten-Stand VOR Multimodell

Anlass (M): (a) Die Gratis-Beigabe (Garn W-G-0015) laeuft aus — die kostenlose Beigabe muss ZENTRAL tauschbar werden (andere Farbe/anderer Artikel), ohne je Wechsel den Agenten umzubauen. (b) Die Werkstatt kommt mit den Paletten nicht klar — aktuelle Palette setzen, sehen was auf einer Palette ist, drucken, Recycling-Sicht. Beides wird VOR AP0-R2/AP1 gezogen. Stoerungsfrei-Prinzip aus §3 gilt unveraendert (DEV-Kopie, Diff-Gate byteident, Abendfenster D-055, 100% Rollback, kundenwirksame Publishes = M).

AP-G · Gratis-Beigabe zentral tauschbar (Vorzug aus §15, minimaler Schnitt)

  • Scope: NUR gratis[] zentral. agent_config.models je aktiver Referenz (W-NM-868, W-NM-868-S): gratis: [{ref, menge}] (price_unit immer 0). EIA v0.4.x liest die Beigabe zur Laufzeit an den 3 bekannten Stellen (Produkte laden / Angebot bauen / Reparatur-Plan). Preis + schnaeppchen bleiben vorerst HART — kommen erst mit AP1. Kleiner Eingriff, kleines Risiko.
  • Ergebnis: Farbwechsel = EINE Config-Aenderung (Board-Panel spaeter; bis dahin G auf Einzelauftrag mit Vorher/Nachher-Beleg). Kein Code, kein Publish je Wechsel.
  • Gate: [DEV]-Kopie, Trockenlauf-Diff byteident mit heutigem Stand (W-G-0015, 4 Rollen, 0 EUR), Publish abends durch M.
  • SOFORT-BRUECKE (falls das Garn vor AP-G-Livegang ausgeht): G tauscht die Artikel-Referenz in EIA v0.4 direkt (Einzelauftrag M, Abendfenster, n8n-Versions-Rollback in Sekunden). Bruecke, kein Ersatz — bleibt hart.
  • M liefert (G1): Ersatzartikel (default_code/Farbe) + Menge + Restbestand-Horizont.

AP-P · Paletten-Stand fuer die Werkstatt (Dashboard + Server-Action + Datum-im-Titel)

Nach Risiko geschnitten, jede Stufe einzeln freigebbar: - P-1 Lesepaket (read-only, zuerst): Wo steht die Palette heute am Ticket (Feld/Titel/Chatter)? Wie zaehlt w6a_palette_next2 exakt (Palette vs. Platz)? Welche Kundenfelder haengen am Ticket (Name, Vorname, Ankunft=Stufe-40-Zeitpunkt?, Tel, Mail)? base.automation-Bestand fuer Stufe-40-Trigger. Null Eingriff. - P-2a Dashboard SICHT + DRUCK (reine Anzeige, null Eingriff in den Ablauf): Seite in der Board-Welt (T5, gleiche Cloudflare-Access-Struktur; Werkstatt als eigene Access-Gruppe). Inhalt: aktuelle Palette gross · Liste je Palette mit Name, Vorname, Ankunftsdatum, Recycling-Status, Tel, Mail, Ticket-Link · Druckblatt je Palette (Print-CSS/PDF) · Recycling-Reiter ("kann recycled werden" nach M-Kriterium G2). PII-Regel: Kundendaten LIVE ueber n8n-Read-Endpoint aus Odoo, NICHT dauerhaft in Supabase (dort nur ticket_id/palette/status) — D-017-Linie, nichts davon ins Repo. - P-2b SETZEN + Server-Action (kleiner Schreib-Baustein, Abendfenster): Wahrheit "aktuelle Palette" = ICP w6.palette.aktuell; das Dashboard setzt sie ueber den auditierten Weg (gov_actions). base.automation bei Stufenwechsel -> 40: schreibt SOFORT die Palette aus dem ICP ins Ticket UND ergaenzt das Datum im Titel — idempotent (nur wenn noch nicht enthalten), damit doppeltes Schieben nichts doppelt. Werkstatt sieht Palette+Datum im Moment des Schiebens, ohne 15-Min-Takt. - P-2c EIA-Anschluss (EIN Schreiber): EIA v0.4.x liest die Palette dann VOM TICKET (statt selbst per w6a_palette_next2 zu ziehen); die RPC wird Fallback/entfaellt. Kleiner Live-Eingriff, gleiche Absicherung wie AP-G (DEV, Diff, Abend, Rollback). - Variante B (falls KEINE neue Odoo-Automation gewuenscht): alles bleibt im EIA — er liest das ICP und schreibt Palette+Datum im 15-Min-Takt. Dafuer Latenz an der Palette. Empfehlung: Variante A (P-2b+P-2c) — an der Palette zaehlt der Moment. Entscheid G4. - Anschluss (notiert, kein Scope): Recycling-Sicht wird spaeter Zulieferer fuer Express-Pfad (§6, Verwertungsprozess) und PPWR (T7).

Ausfuehrung

G (P-1-Reads, [DEV]-Flows, agent_config-Schema, Server-Action-Spez, n8n-Endpoint) · T5 (Dashboard-Seiten — nach Board-Merge v0.9.6) · M (Publishes, ICP-/Automation-Klicks bzw. Einzelfreigaben, Access-Zugaenge Werkstatt, Ersatzartikel-Wahl).

Reihenfolge NEU

AP-G -> AP-P (P-1 -> P-2a -> P-2b -> P-2c) -> danach unveraendert AP0-R2 -> AP1 -> AP2 -> AP3 parallel AP4 -> AP5 (AP6 optional). Multimodell/Express/Erinnerungen ruecken nach hinten, die Planung dazu bleibt wie sie ist.

M-Entscheide §16

  • G1 Ersatz-Gratisartikel: welche Farbe/Referenz + Menge? Wann endet der Restbestand (entscheidet, ob die Sofort-Bruecke gebraucht wird)?
  • G2 Recycling-Kriterium: was genau gilt als "kann recycled werden"?
  • G3 Dashboard-Ort/Zugang: Seite in der Board-Welt (Empfehlung) oder eigene Adresse? Wer aus der Werkstatt braucht Zugang (Mails fuer Cloudflare Access)?
  • G4 Paletten-Schreiber: Variante A (Server-Action sofort, Empfehlung) oder B (nur EIA, 15-Min-Takt)?
  • G5 Titel-Format: welches Datum (Ankunft bei Stufe 40?) und wie im Titel (z.B. Anhang " [Ank. 10.08.]")?

§16a ENTSCHEIDE zu §16 (M, 10.08. abends)

  • G1 STRUKTUR ENTSCHIEDEN — Beigabe wird PARAMETER: je Referenz {artikel, menge, aktiv} — setzbar oder LEER (leer = keine Beigabe, Angebot ohne Gratis-Zeile). Zentrale Wahrheit bleibt agent_config (Laufzeit-Read des EIA). Pflegeort auf M-Wunsch: EIGENER _CONFIG-Reiter im Aktions-Spreadsheet — ein gesicherter Sync-Flow uebertraegt nach agent_config mit Gates (Artikel existiert in Odoo, Menge plausibel 0-20, sonst KEINE Uebernahme + Alarm; letzter guter Stand bleibt wirksam). EIA liest NIE das Sheet direkt — die Angebots-Entscheidung haengt nie an Sheet-Verfuegbarkeit (§13-Linie). Nebengewinn: der _CONFIG-Reiter ist dieselbe Struktur, die AP1 fuer die Modell-Zeilen braucht — Vorleistung, kein Wegwerf. OFFEN bleibt (dringend): konkreter Ersatzartikel (Farbe/default_code) + Menge + Restbestand-Horizont → entscheidet, ob die Sofort-Bruecke gebraucht wird.
  • G2 ENTSCHIEDEN — Recycling-Kriterium: recycelbar, wenn (a) 12 Wochen vergangen sind [Anker: Ankunft/Stufe-40-Datum — ANNAHME, M bestaetigt] OHNE dass ein Kauf zustande kam, ODER (b) 30 Tage nach dem Kauf UND keine Rueckgabe erfolgte. P-1 klaert die Belegfelder: Kauf-Verknuepfung (Angebot->Auftrag bestaetigt/bezahlt) + Rueckgabe-Erkennung (Retoure/Gutschrift).
  • G3 ENTSCHIEDEN — Muster "Schnaeppchen buchen": das Paletten-Dashboard uebernimmt Optik, Struktur und Ladeverhalten des bestehenden Tools "Schnaeppchen buchen"; gleiche Zugangswelt. P-1 nimmt das Referenz-Tool auf (wo es laeuft, Stack, Access-Gruppe). OFFEN: zusaetzliche Werkstatt-Zugaenge, falls abweichend.
  • G4 ANGENOMMEN — Variante A (Server-Action schreibt sofort beim Schieben; war Ms eigener Vorschlag + G-Empfehlung). Einwand jederzeit moeglich, solange nicht gebaut.
  • G5 ENTSCHIEDEN — ja: Ankunftsdatum bei Stufenwechsel->40 in den Titel, idempotent.

§16b ENTSCHEIDE Gratis-Beigabe (M, 10.08. spaetabends) + Stand

  • Fallback: W-G-0020, automatisch wenn Bestand W-G-0015 unter Schwelle 100 sinkt; Entwarnung zurueck auf Primaer. Warn-Mail bei jedem Schwellen-Ereignis (nur Statuswechsel, kein Spam).
  • Systematik fuer Rollout: je Referenz (Zeile) gratis_primary{ref,menge} · gratis_fallback{ref,menge} · threshold — gleiche Struktur wie kuenftige _CONFIG-Zeilen; neue Modelle = neue Zeile, kein Code.
  • Umgesetzt: W6-GRATIS-WATCH v0.1 [DEV] live (stuendlich; Beleg-Testlauf: 0015=445, 0020=473 → primary). agent_config erweitert (auditiert).
  • Offen fuer Sheet-Pflege (_CONFIG-Reiter): M liefert Spreadsheet-Link + legt Google-SHEETS-Credential in n8n an (einmalig OAuth); danach Sync Reiter->agent_config mit Gates (AP-G2). Reiter-Spalten (Vorschlag): referenz | aktiv | gratis_artikel | gratis_menge | fallback_artikel | fallback_menge | schwelle | warn_email | bemerkung.
  • Garantielabel: 17/19 belegt (gread 9495); FEHLEN 1235 Pro + 5000 Pro; Tests per M-Entscheid entfallen (TESTPROTOKOLL-Vermerk).