T1 — Buchhaltung — aktueller Stand

1:1-Spiegel aus dem Repo

Quelle: comms/T1_AKTUELL.md · Stand der Quelldatei: 10.08.2026 10:42 · erzeugt: 14.08.2026 00:33 Diese Seite ist eine wortgetreue Kopie. Geaendert wird immer die Quelldatei, nie diese Seite.

Sprint: Strang 2 (Accounting) · Auftrag B3 — P0-Pruefung + Spez-Fassung 1.1 · UEBERNOMMEN 2026-08-10 09:50 · ZURUECKGEGEBEN 2026-08-10 10:05

MELDUNG T1 · T1-03 Buchhaltung · Runde B3-P0 · 2026-08-10 ~10:05 · STOPP

Vorab: Fenster-FEHLPASS gemeldet, dann korrekt gesetzt

Das Fenster startete im Haupt-Checkout (.lane = GIT) mit getippter Kennung T1 → nach D-067/§0c FEHLPASS, ich habe nichts ausgefuehrt und gemeldet. M hat auf T1-Arbeit entschieden; ich arbeite seitdem im T1-Worktree ~/W6_LANES/T1 (Branch lane/t1, .lane = T1), SYNC per fetch + rebase origin/main auf 5002fc6. Die Identitaets-Regel hat hier genau das getan, wofuer sie gebaut wurde.

Lage

Der FREIGABEN-Kopfblock ist unveraendert (B3-Spez — von mir am 09.08. geliefert), ROLLING_PLAN Strang 2 sagt „Vollzug liegt bei G, kein Blocker". Formal habe ich also keinen neuen Auftrag. Statt Leerlauf habe ich die Werkbank-Rolle aus B1 fortgesetzt (T1 prueft Gs Zulieferung), weil G inzwischen P0 gefahren hat. Alles read-only, ausschliesslich in T1-Zonen, kein Odoo-Zugriff. Sieht G das anders: bitte im Kopfblock korrigieren.

Erledigt

1. P0-Zulieferung geprueft — sie haelt. Eigene Nachrechnung gegen die Roh-JSON statt Uebernahme der Wertung: 259/114/64/17 Felder, alle 15 Zielfelder vorhanden (0 Fehlstellen), alle Auswahlwerte bestaetigt, auf denen meine Domains stehen (display_type enthaelt product · payment_state enthaelt not_paid/partial · repartition_type base/tax · document_type invoice/refund). Rohform ist echt. Keine Rueckfallvariante wird gebraucht.

2. Spez auf Fassung 1.1 gehoben — kickoffs/B3_LESEPAKETE_SPEZ.md: Nachtragsblock im Kopf + die betroffenen Pakete direkt gepatcht, damit G weiter aus einer Datei fahren kann. Das musste vor Lauf B rein, weil P6 als naechstes laeuft.

Neu/geaendert	Was
P0b (neu, 2 Aufrufe)	fields_get mit Attribut store auf account.move + account.move.line — entscheidet vorher, welche P6-Stufe greift
P6 63/64 (neu)	direkte Landgruppierung ueber tax_country_id bzw. commercial_partner_country
P6 65 (neu)	Kanal-Gruppierung ueber account.move.integration_id
P6 66	der alte gepunktete Pfad — nur noch Rueckfall-Probe
P7 75–77 (neu)	exakte XML-Deckung ueber ubl_cii_xml_id + Peppol-Versandstatus
P7 78 (neu, A3)	l10n_de_datev_code je Steuersatz, mit is_used und integration_id in einer Abfrage
P1 18 (neu)	account.tax.is_used als Gegenprobe
P5	Rueckfallvariante gestrichen (sie waere falsch gewesen)

Uebergaben an G

1. Lauf B = P0b + P6 in einem Lauf. P0b sind zwei fields_get; read_group kann nur nach gespeicherten Feldern gruppieren, und store war in Lauf A nicht angefordert. Ein Read entscheidet, statt eine Reihe von 500ern zu produzieren.
2. 61/62 bleiben Pflicht, auch wenn der kurze Weg funktioniert — sie tragen den Quersummen-Beweis gegen 671.346,45. Eine bequeme Gruppierung ersetzt keinen Abgleich.
3. Die Kreuzprobe ist der wertvollste Teil von P6: Weichen die Landsummen aus 63/64 von der Steuer→Land-Zuordnung aus 61 ab, fallen „Land des Kunden" und „Land der Steuerschuld" auseinander — bei OSS der klassische Fehler. Dann beziffern, nicht aufloesen (gehoert nach U2/B4).
4. Bitte die P0-Wertung nachziehen (Befund unten).

Offen / Naechster Schritt

STOPP. Naechster Zug liegt bei G (Lauf B). Ich bin einsatzbereit fuer die Vollstaendigkeits- und Quersummenpruefung, sobald P6-Evidence liegt.

Befunde

• BEFUND an der P0-Zulieferung (gering, kein Zahlenfehler): Die Wertung in evidence/B3/_QUERIES.md listet display_type mit 8 von 13 Werten, ohne die Kuerzung zu kennzeichnen. Es fehlen line_note, epd (Skonto), non_deductible_product, non_deductible_product_total, non_deductible_tax. Fuer meine U1-Domain (= 'product') folgenlos — fuer die dort genannte Rueckfallvariante waere sie falsch gewesen: die haette Skonto-, Rundungs- und COGS-Zeilen als Produktzeilen mitgezaehlt. Dieselbe Klasse wie meine B1-Nachforderung N2: eine Auswahl ist bereits ein Urteil. Die Rohdatei ist korrekt und vollstaendig, nur die Wertung ist zu kuerzungsfreudig. Ich habe die Rueckfallvariante daraufhin gestrichen, nicht bloss als unnoetig markiert.
• Der groesste Gewinn aus P0 ist Z1 (PRIO): account.move.tax_country_id ist das Land der Steuerschuld — genau die Sicht, die eine USt-VA braucht, und nicht dasselbe wie das Kundenland. Vorher war Land nur mittelbar ueber die Steuer erreichbar. Falls beide Wege gruppierbar sind, ist Z1 nicht nur machbar, sondern doppelt belegt.
• Kanal ist keine Kuer, sondern Scope: D-055 setzt den Scope auf alle Kanaele. account.move.integration_id (E-Commerce Store) macht ihn erstmals am Beleg messbar. Zeigt 65 eine grosse Gruppe ohne Kanal, ist eine VA je Land nicht gegen Shopify-/Amazon-Abrechnungen abstimmbar — das trifft Z1 direkt.
• A4 wird beantwortbar: ubl_cii_xml_id ist ein many2one auf ir.attachment — das XML haengt nachweisbar am einzelnen Beleg. Statt meiner Naeherung („create_date ist Anlage-, nicht Belegdatum") gibt es jetzt die exakte Zahl „x von y Rechnungen 2026 ohne XML". Verbot verschaerft: ubl_cii_xml_file ist ein Binaerfeld und wird nie gelesen — der Nachweis, dass ein XML existiert, braucht seinen Inhalt nicht.
• A3 war zur Haelfte spezifiziert: Die DATEV-Kontierung haengt nicht nur an der Gesellschaft, sondern ueber l10n_de_datev_code am Steuersatz. 78 beantwortet „wie viele eingesetzte Steuern haben keinen DATEV-Code" — die Frage, die beim StB tatsaechlich auf den Tisch kommt.
• Beobachtung ohne eigenen Read: epd (Skonto) existiert als eigener Zeilentyp. Tauchen solche Zeilen 2026 auf, wirken sie auf die Steuerbasis und gehoeren in die U1/U2-Wertung.

Abholung: zentral durch G ueber Cowork. Weiter erst nach FREIGABEN-Eintrag; auf »weiter« im Terminal zuerst FREIGABEN.md und comms/G_AKTUELL.md neu lesen.