OpenGewerk 0.7.0

Die siebte Fassung bringt den größten Teil von Phase 2, dem Kern für Elektro und PV. Zu den Prüfungen kommen das Protokoll der Wiederholungsprüfung nach DIN VDE 0105-100, das Geräteverzeichnis mit der Prüfung nach DGUV Vorschrift 3, die Prüfung der Elektroinstallation als Prüfbericht je Objekt und die Prüffrist der Erstprüfung, jeweils mit der Frist der nächsten Prüfung. Für PV, Wallbox und Speicher gibt es das Inbetriebsetzungsprotokoll nach VDE-AR-N 4105, die PV-Anlagendokumentation, die Netzbetreiber mit Anmeldung, Fertigmeldung und der Ausfüllhilfe für das Marktstammdatenregister, die Inbetriebnahme von Wallbox und Speicher und die Förderunterlagen. Am Auftrag stehen jetzt das Abnahmeprotokoll mit der Gewährleistungsfrist, die Aufforderung zur Abnahme und die Mängel mit Status und Mängelbericht.

Dazu kommen Material und Lager: Verkaufspreise aus Einkaufspreis und Aufschlag, der Metallzuschlag, der Import aus DATANORM mit eigenen Bildschirmen, die Kennzeichnung einer Haltbarkeitsgarantie des Herstellers, Lagerorte und Fahrzeuge mit Bestand, der Lieferschein und das Scannen von Material auf der Baustelle. Für die Leute im Betrieb gibt es die Mitarbeiterakte, Urlaub und Krankheit mit den gesetzlichen Feiertagen, das Zeitkonto, die Plantafel und das Kalender-Abo. Entwürfe lassen sich löschen, im Büro und auf der Baustelle.

Noch nicht dabei sind aus Phase 2 die Serviceaufträge, der Notdienst, Wartungsverträge mit Dauerrechnung, die Erinnerungen an Kunden, Leads und die Kommunikationshistorie, die DSGVO-Funktionen, die Hilfe und der Import aus Messgeräten. Ein Update braucht keinen eigenen Schritt, die neuen Migrationen laufen beim Start. Vor dem produktiven Einsatz stehen weiter die fachliche Abnahme der Regelpakete und Grenzwerte (#31) und der Praxistest der E-Rechnung bei einem echten Empfänger (#133).

Hinzugefügt

• Mängel und Reklamationen mit Status und Mängelbericht (#311), nach der Feature-Gliederung v2.61 und den Tafeln aus Version 123 des Canvas: Ein Mangel hängt an einem Auftrag, an einer Anlage oder an beiden, mit Beschreibung, wer ihn gemeldet hat und wann, der Frist des Kunden zur Beseitigung und Fotos, die bei den Dateien des Auftrags oder der Anlage liegen und dem Mangel zugeordnet sind (Migration 0119). Auf der Baustelle entsteht er am Auftrag ohne Netz, im Büro auch als Reklamation an einer Anlage. Jeder Schritt (in Bearbeitung, behoben, abgenommen) ist ein eigener Eintrag mit Person und Uhrzeit; abgenommen ist ein Mangel erst mit Name und Unterschrift des Kunden auf dem Gerät, danach ändert er sich nicht mehr. Die Vorbehalte eines unterschriebenen Abnahmeprotokolls werden von der Datenbank zu Mängeln, eine Zeile je Mangel. Ein Mangel nach der Abnahme zeigt, ob der Tag seiner Meldung in der Gewährleistung liegt. Aus der Frist des Kunden wird die neue Frist „Mangel beseitigen“, und je Auftrag gibt es den Mängelbericht als PDF mit Verlauf, Unterschrift und Fotos. Warum: Bisher standen Mängel nur als Text im Abnahmeprotokoll, ohne Stand, ohne Frist und ohne Nachweis, wann sie beseitigt und abgenommen wurden.

• Abnahmeprotokoll nach § 640 BGB mit Gewährleistungsfrist ab Abnahme (#310), nach der Feature-Gliederung v2.60 und den Tafeln aus Version 121 des Canvas: Die Abnahme ist ein Formular am Auftrag, auf dem Gerät ausgefüllt und vorbelegt aus Kunde und Auftrag, mit dem Ergebnis (abgenommen, mit Vorbehalten, verweigert), den Vorbehalten wegen bekannter Mängel, dem Vorbehalt einer Vertragsstrafe, Bauwerk, VOB/B und Wartung, Foto und den Unterschriften von Auftraggeber und Auftragnehmer; danach ändert es sich nicht mehr. Bauwerk und VOB/B stehen am Auftrag, mit einem Vorschlag nach der Art (Migration 0118). Aus dem letzten unterschriebenen Protokoll wird die neue Frist „Gewährleistung endet“, fünf oder zwei Jahre nach § 634a BGB, vier nach § 13 Abs. 4 VOB/B und bei VOB/B ohne übertragene Wartung zwei für die wartungsbedürftigen Teile, als Regelpaket warranty. Das PDF des Protokolls nennt das Ende der Gewährleistung; die Aufforderung zur Abnahme mit Frist entsteht am Auftrag als Brief, bei einer privaten Kundin mit dem Hinweis nach § 640 Abs. 2 Satz 2 BGB. An der Anlage folgt die Gewährleistung aus der Abnahme, die Herstellergarantie hat ein eigenes Feld. Warum: Mit dem Tag der Abnahme beginnt die Gewährleistung, und bisher hielt OpenGewerk weder den Tag noch die Frist.

• Wallbox und Speicher: Inbetriebnahme, Förderunterlagen und Prüfintervalle (#307), nach der Feature-Gliederung v2.59 und den Tafeln aus Version 120 des Canvas: Eine Wallbox bekommt ihr Inbetriebnahmeprotokoll als Erstprüfung nach DIN VDE 0100-600 mit den Anforderungen der DIN VDE 0100-722, mit RCD je Ladepunkt höchstens 30 mA, Schutz bei Gleichfehlerströmen (RCD Typ B oder Fehlergleichstrom-Überwachung höchstens 6 mA, beides als Regel im Paket Elektro 0.9.0) und der Prüffrist bis zur ersten Wiederholungsprüfung, aus der die Frist an der Anlage wird; der Prüfbericht je Objekt nennt es als Prüfung der Anlage. Ein Speicher bekommt das Inbetriebnahmeprotokoll nach den Angaben des Herstellers neben dem nach VDE-AR-N 4105, das allein hinter der Fertigmeldung an den Netzbetreiber geht. Speicher und Wallbox nennen ihre nutzbare Kapazität und Bemessungsleistung (Migration 0117), und Anmeldung, Fertigmeldung und Ausfüllhilfe drucken sie statt leerer Zeilen. Förderprogramme sind Vorlagen unter „Stammdaten“: die Nachweise eines Programms in seiner Reihenfolge, aus OpenGewerk oder vom Betreiber, und der Text der Fachunternehmererklärung mit Platzhaltern. An einer PV-Anlage, einem Speicher oder einer Wallbox entstehen daraus die Förderunterlagen als ein PDF: die Liste der Nachweise mit dem, was beiliegt, fehlt oder der Betreiber bringt, dahinter Erklärung, Seriennummern, Inbetriebnahmeprotokolle, Fotos und Rechnungen. Neue Rechte „Förderprogramme ansehen“ und „Förderprogramme pflegen“ für Inhaber und Büro. Warum: Nach der Montage einer Wallbox oder eines Speichers fehlten Protokoll, Frist und die Unterlagen für die Förderung, und Förderprogramme wechseln zu oft, um sie in den Code zu schreiben.

• Netzbetreiber, Netzbetreiber-Anmeldung und die Ausfüllhilfe für das Marktstammdatenregister (#306), nach der Feature-Gliederung v2.58 und den Tafeln aus Version 117 des Canvas: Unter „Stammdaten“ pflegen Inhaber und Büro ihre Netzbetreiber mit dem, was sie verlangen, ihrem Portal, einem Ansprechpartner und der Eintragung des Betriebs in ihr Installateurverzeichnis (Nummer, gültig bis, verantwortliche Elektrofachkraft). Vor dem letzten Tag einer Eintragung erinnert die neue Frist „Eintragung im Installateurverzeichnis läuft ab“ (Paket Elektro 0.8.0). Eine PV-Anlage und ein Speicher oder eine Wallbox, die zu keiner PV-Anlage gehören, nennen ihren Netzbetreiber und die Kennung dort (Migration 0116). Daraus entstehen Anmeldung und Fertigmeldung als vorausgefüllte Datenblätter mit der Eintragung des Betriebs als E-Installateur-Nachweis; hinter der Fertigmeldung folgen die unterschriebenen Inbetriebsetzungsprotokolle. Die Ausfüllhilfe nennt jede Frage, die das Register nach der Anlage zur MaStRV an Betreiber, Solareinheit, EEG-Anlage und Speicher stellt, mit der Antwort aus der Anlage oder einer Zeile für den Betreiber, und oben seine Frist von einem Monat nach der Inbetriebnahme (§ 5 Abs. 5 MaStRV, als Regel im Paket). Neue Rechte „Netzbetreiber ansehen“ und „Netzbetreiber pflegen“ für Inhaber und Büro. Warum: Jede PV-Anlage, jeder Speicher und jede Wallbox geht an den Netzbetreiber, und alles, was er und das Register fragen, steht schon in Kunde, Objekt und PV-Struktur.

• Die PV-Anlagendokumentation (#305), nach der Feature-Gliederung v2.57 und den Tafeln aus Version 115 des Canvas: die Prüfung der Gleichstromseite nach DIN EN IEC 62446-1 als Formular, je String aus der PV-Struktur mit Polarität, Leerlaufspannung, Kurzschlussstrom und Isolationswiderstand gegen den Mindestwert von 1 MΩ (Paket Elektro 0.7.0); die Ertragsprognose als Wert mit Quelle an der PV-Anlage (Migration 0115); „Stringplan und Komponentenliste“ als PDF aus der Struktur; und an der PV-Anlage im Büro „Übergeben“, das die Mappe für den Betreiber festhält: Komponenten, Stringplan, Ertragsprognose und die letzten unterschriebenen Protokolle, so wie an diesem Tag, als ein PDF. Eine Übergabe lässt sich weder ändern noch löschen. Warum: Ein Betrieb übergibt jede PV-Anlage mit ihren Unterlagen, und was er übergeben hat, muss er später genau so wieder zeigen können.

• Das Inbetriebsetzungsprotokoll nach VDE-AR-N 4105 (#304), nach der Feature-Gliederung v2.56 und den Tafeln aus Version 113 des Canvas: An einer PV-Anlage oder einem Speicher entsteht es nach Formular F.9 der Fassung 2026-03, vorbelegt aus dem Kunden des Objekts und der PV-Struktur (Anlagenbetreiber mit Anschrift, Wechselrichter, Speicher, Zählernummer, SAmax, PAmax und Modulleistung). Die Begrenzung der Einspeisung auf 60 Prozent ohne intelligentes Messsystem steht als Regel mit Gültigkeit ab dem 25.02.2025 im Paket Elektro 0.6.0 und wird gemessen wie ein Messwert. Anlagenbetreiber und Elektrofachbetrieb unterschreiben auf dem Gerät, der Betrieb zuletzt; dafür nimmt der Schritt „Unterschreiben“ auf der Baustelle jetzt alle Unterschriften eines Formulars auf. Neu in der Formular-Engine des Fundaments ist das Feld „Datum“, hier für den ersten Netzparallelbetrieb, und ein Formular kann sagen, für welche Arten von Anlagen es ist, was es aus der Struktur vorbelegt und dass es keine Prüfung ist: der Prüfbericht je Objekt nennt es nicht. Warum: Jeder PV-Anlage folgt das Protokoll für den Netzbetreiber, und alles, was es fragt, steht schon in Kunde, Objekt und PV-Struktur.

• Die Prüfung der Elektroinstallation als Prüfbericht je Objekt (#302), nach der Feature-Gliederung v2.53 und den Tafeln aus Version 109 des Canvas: Am Objekt im Büro öffnet „Prüfung der Elektroinstallation“ ein PDF, dessen erste Seite das Ergebnis des Ganzen nennt, je Anlage die letzte unterschriebene Prüfung der ganzen Anlage (Wiederholungsprüfung oder Erstprüfung) und je Gerät die letzte Prüfung nach DGUV Vorschrift 3, jeweils mit Ergebnis und dem Tag der nächsten, dazu den nächsten Prüftag am Objekt. Dahinter folgt das Protokoll jeder Anlage, wie es für sich gedruckt wird. Eine Erstprüfung nach einer Erweiterung oder Änderung zählt nicht als Prüfung der ganzen Anlage, eine Heizung erscheint nur, wenn sie mit einem Protokoll einer Anlage geprüft ist. Warum: Ein Betrieb gibt seinem Kunden nach der Prüfung nach DIN VDE 0100-600, DIN VDE 0105-100 und DGUV Vorschrift 3 einen Bericht über das ganze Objekt, ohne etwas doppelt zu erfassen; die Fristen bleiben an den Protokollen.

• Die Erstprüfung nach DIN VDE 0100-600 nennt die Prüffrist bis zur ersten Wiederholungsprüfung (#814), nach der Feature-Gliederung v2.52: Fassung 3 des Protokolls hat das Feld im Ergebnis, mit den Prüffristen aus Tabelle 1A der DGUV Vorschrift 3 als Hinweis. Bei einer Neuanlage ist es Pflicht, und aus dem unterschriebenen Protokoll wird die Frist „Wiederholungsprüfung der Anlage“; nach einer Erweiterung oder Änderung bleibt die Frist der letzten Prüfung stehen, das Formular und das PDF sagen das an Stelle des Tags. Protokolle der Fassungen 1 und 2 nennen keine Frist und lassen eine bestehende stehen; vorher hätte eine solche Erstprüfung nach einer Wiederholungsprüfung deren Frist gelöscht, sobald das Formular das Feld bekommt. Warum: Nach einer Neuanlage erinnerte OpenGewerk erst, wenn die erste Wiederholungsprüfung unterschrieben war, also nie von selbst an diese erste.

• Das Geräteverzeichnis und die Prüfung nach DGUV Vorschrift 3 (#303), nach der Feature-Gliederung v2.51 und den Tafeln aus Version 106 des Canvas: Jedes Objekt hat ein Verzeichnis seiner Geräte, die an keinem Stromkreis hängen, mit Inventarnummer, Bezeichnung, Hersteller, Typ, Seriennummer, Schutzklasse, ortsveränderlich oder ortsfest, Standort und der Länge der Anschlussleitung. Im Büro steht es als Karte am Objekt und als eigene Seite mit Suche, Filtern und dem Prüfbericht als PDF; ein Gerät hat seine Prüfprotokolle wie eine Anlage. Auf der Baustelle führt die Karte „Geräte“ am Auftrag zu den Geräten des Objekts: ein Tippen öffnet den Entwurf von heute oder beginnt eine Prüfung mit dem letzten Protokoll des Geräts als Vorlage, ein fehlendes Gerät wird dort angelegt und gleich geprüft, alles ohne Netz, und nach der Unterschrift geht es zum nächsten Gerät. Das Protokoll prüft nach DIN EN 50699 (VDE 0702) oder nach Instandsetzung nach DIN EN 50678 (VDE 0701) Schutzleiterwiderstand, Isolationswiderstand, Schutzleiter- und Berührungsstrom; die Grenzwerte nach DGUV Information 203-070, Tabelle 1, richten sich nach der Schutzklasse und beim Schutzleiterwiderstand nach der Länge der Leitung. Die Prüffrist in Monaten nennt die Richtwerte aus Tabelle 1B der DGUV Vorschrift 3, und aus dem letzten unterschriebenen Protokoll wird je Gerät eine Frist; die Fristen eines Objekts, die am selben Tag für dieselbe Person anstehen, teilen sich eine Aufgabe. Dafür kennt die Regel-Engine Milliohm, Mikroampere und Millimeter. Grenzwerte und Prüffristen gehen zur fachkundigen Abnahme in #31. Warum: Die Prüfung ortsveränderlicher Geräte ist für viele Elektrobetriebe Arbeit an jedem Tag, bei einem Kunden schnell ein paar hundert Geräte, und bis jetzt kannte OpenGewerk nur Anlagen.

• Das Prüfprotokoll der Wiederholungsprüfung nach DIN VDE 0105-100 (#301), nach der Feature-Gliederung v2.50 und den Tafeln aus Version 104 des Canvas: An jeder Anlage steht es neben der Erstprüfung, mit Besichtigen, Erproben und Messen je Stromkreis aus dem Stromkreisverzeichnis. Den Isolationswiderstand misst es ohne oder mit angeschlossenen Verbrauchern, jedes mit seinem Mindestwert nach DGUV Information 203-072, Tabelle 11 (0,230 MΩ und 0,069 MΩ bei 230 V); Schleifenimpedanz und Fehlerstromschutz prüft es wie die Erstprüfung. Im Ergebnis nennt es die Prüffrist bis zur nächsten Prüfung in Monaten, mit den Prüffristen aus Tabelle 1A der DGUV Vorschrift 3 als Hinweis, und darunter den Tag, auf den sie fällt; das PDF druckt ihn mit. Aus dem letzten unterschriebenen Protokoll einer Anlage wird eine Frist „Wiederholungsprüfung der Anlage“, die erste Fristart eines Gewerks: 60 Tage vorher eine Aufgabe und eine Erinnerung für die Person, die unterschrieben hat; ein neues Protokoll verschiebt sie, mit der Anlage entfällt sie. Ein neues Protokoll nimmt das letzte unterschriebene der Anlage als Vorlage, auch aus dem anderen Formular, und übernimmt nur, was das neue Formular dafür kennzeichnet. Die Grenzwerte gehen zur fachkundigen Abnahme in #31. Warum: Ein Elektrobetrieb prüft die Anlagen seiner Kunden wiederkehrend, und bis jetzt ließ sich nur die Erstprüfung dokumentieren und niemand erinnerte an die nächste.

• Nachrichten zum Urlaub (#806), nach der Feature-Gliederung v2.49 und den Tafeln aus Version 101 des Canvas: Ein neuer Urlaubsantrag kommt per Push zu allen im Betrieb, die Abwesenheiten pflegen, außer zu der Person, die ihn stellt; die Entscheidung darüber kommt zu der Person, die ihn gestellt hat. Die Nachricht nennt nur den Zeitraum und „freigegeben“ oder „abgelehnt“, keinen Namen und keine Antwort. Unter „Konto“ und im Menü der Baustelle stehen dafür die Anlässe „Urlaubsanträge“ und „Entscheidung über Urlaub“, einzeln abschaltbar. Warum: Bis dahin erfuhr niemand von einem Antrag, solange er nicht selbst nachsah.

• Das Kalender-Abo (#291), nach der Feature-Gliederung v2.48 und den Tafeln aus Version 100 des Canvas: Unter „Konto“ und unter „Meine Termine“ erstellt jede Person die Adresse ihres eigenen Kalenders, im Format iCalendar, das Google Kalender, Apple, Outlook, Thunderbird und auf Android ICSx⁵ lesen. Der Kalender zeigt ihre Termine mit Auftrag, Kunde, Anschrift und Notiz, Serien mit Regel und ausgenommenen Tagen, in deutscher Zeit, von 90 Tagen zurück an. Die Adresse steht nur gleich nach dem Erstellen da, gespeichert ist nur ihr Hash; eine neue beendet die alte, und ein beendetes Abo und das einer Person, die nicht mehr im Betrieb arbeitet, liefern einen leeren Kalender. Warum: Ein Monteur will seine Termine im Kalender seines Telefons sehen, ohne OpenGewerk zu öffnen, und OpenGewerk soll dafür keine Zugangsdaten fremder Kalender halten; ein CalDAV-Server, nur lesend, folgt später (#810).

• Die Plantafel (#290), nach der Feature-Gliederung v2.47 und den Tafeln aus Version 98 des Canvas: Unter „Arbeit“, „Plantafel“ steht für jede Person mit Zugang eine Zeile, eine Woche oder vier Wochen nebeneinander, dazu die freigegebenen Abwesenheiten und die Feiertage des Betriebs; am Rand warten die offenen Aufträge, die ab heute keinen Termin haben. Ein Termin hängt an einem Auftrag und hat Beginn, Ende, eine kurze Notiz und die Personen, die hingehen; Serien werden als Regel nach RFC 5545 gespeichert (RRULE und EXDATE), und ein einzelner Tag lässt sich ausnehmen. Verschoben, verlängert und umgehängt wird mit Maus oder Finger und ebenso im Formular; ein Termin in einer Abwesenheit bekommt eine Warnung. Wer einen Termin bekommt, wird dem Auftrag zugeordnet und hat ihn damit auf dem Gerät; über einen neuen, geänderten oder entfallenen Termin sagt eine Push-Nachricht Bescheid (Anlass „Termine“), und auf der Baustelle bestätigt der Monteur unter „Meine Termine“ die Fassung, die er gesehen hat. Termine reisen auf die Geräte, geschrieben werden sie an den Routen unter /appointments und nur in der Fassung, die die Tafel gelesen hat (Migration 0111_appointments, Nachtrag in ADR 0005). Warum: Ein Betrieb mit mehreren Monteuren plant bisher an der Wand oder in einer Tabelle, und der Monteur erfährt den Termin am Telefon; jetzt steht er auf dem Gerät, mit dem Auftrag, den er dafür braucht.

• Das Zeitkonto (#289), nach der Feature-Gliederung v2.46 und den Tafeln aus Version 97 des Canvas: Unter „Zeiterfassung“ steht in der Woche das Soll jedes Tages mit dem Saldo bis gestern, darunter die Karte „Zeitkonto“ mit dem Übertrag aus dem Vorjahr, Soll, Ist und Saldo je Monat und dem Stand; auf der Baustelle zeigt die Karte „Zeitkonto“ unter „Zeiten“ den eigenen Stand, /m/zeitkonto die Woche und die Monate. Das Soll ist die vereinbarte Arbeitszeit des Tages, Feiertage, freigegebener Urlaub und Krankheit nehmen es, ein halber Tag die Hälfte; es zählen Arbeit und Fahrt aus den gültigen Einträgen, eine Korrektur an ihrem eigenen Tag, gezählt wird bis gestern, und der Saldo läuft über den Jahreswechsel weiter. Das Konto rechnet der Server (GET /time-account, /time-account/mine), weil Akte und Abwesenheiten auf keinem Gerät liegen. Damit muss niemand mehr Überstunden aus Stundenzetteln zusammenzählen; Auszahlen und Übertragen gehören zum Lohnexport.

• Urlaub und Krankheit (#288), nach der Feature-Gliederung v2.45 und den Tafeln aus Version 95 des Canvas: Unter „Personal“, „Abwesenheiten“ trägt das Büro Urlaub und Krankheit ein, ganze und halbe Tage, gibt Anträge frei oder lehnt sie mit einer Antwort ab und hält je Person und Jahr Anspruch und Übertrag; den Übertrag schlägt die Anwendung aus dem Rest des Vorjahrs vor, verfallen lässt sie ihn nicht von selbst (Migration 0110_absences). Ein Monteur beantragt Urlaub auf der Baustelle unter „Zeiten“, „Urlaub“ und sieht dort seine Abwesenheiten mit Art und Antwort; ohne Netz sagt die Seite das. Ein Urlaubstag ist ein Arbeitstag nach der vereinbarten Arbeitszeit, der kein Feiertag ist, und ein Tag, an dem jemand krank ist, zählt nicht als Urlaub (§ 9 BUrlG). Von einer Krankheit hält die Anwendung nur Dauer, kein Notizfeld. Pflegen darf Abwesenheiten das neue Recht „Abwesenheiten pflegen“, von Haus aus Inhaber und Büro; wer nur plant, bekommt über GET /absences/planning „absent“ statt der Art, als Datenquelle für die Plantafel (#290). Warum: Moritz hat am 27.09. und 01.11.2026 entschieden, dass zur Urlaubsverwaltung Anspruch, Rest und Antrag gehören und wer die Art einer Krankheit sieht, einem Gesundheitsdatum.

• Die gesetzlichen Feiertage aller 16 Länder als Regelpaket holidays (#288), mit Fundstelle und dem Tag, ab dem ein Feiertag galt; das Bundesland und die örtlichen Feiertage (Mariä Himmelfahrt und Augsburger Friedensfest in Bayern, Fronleichnam in Teilen Sachsens und Thüringens) stellt der Inhaber unter Einstellungen, „Feiertage“ ein. Für den Buß- und Bettag kennt das Fundament die Einheit wednesday_before, für die Sonntage in Hessen gilt die Regel holiday.every_sunday. Warum: ohne Feiertage zählte jeder Urlaub über Ostern zwei Tage zu viel, und das Zeitkonto (#289) braucht dieselben Tage.

• Die Mitarbeiterakte (#287), nach ADR 0016, der Feature-Gliederung v2.44 und den Tafeln aus Version 93 des Canvas: Unter „Personal“, „Mitarbeiter“ liegt je Person eine Akte, mit Zugang oder ohne, mit Name, Eintritt und Austritt (Migration 0109_people). Die vereinbarte Arbeitszeit steht als Stunden je Wochentag ab einem Tag und gilt bis zum Tag vor der nächsten; hat ihr Tag begonnen, bleibt sie, wie sie ist, und eine neue beginnt frühestens heute. Die Qualifikationen hängen an der Person, mit einer Art aus dem Katalog (Elektrofachkraft, PV-Zertifizierung, Höhenarbeit, Führerschein) oder einer eigenen Art des Betriebs, mit gültig bis und Notiz; die Akte zeigt, was bald abläuft und was abgelaufen ist. Lesen und pflegen darf die Akten nur der Inhaber, mit den neuen Rechten „Akten der Mitarbeiter ansehen“ und „Akten der Mitarbeiter pflegen“; jede Person liest ihre eigene unter „Konto“ in der Karte „Meine Akte“. Läuft eine Qualifikation ab, legt die Fristen-Engine 60 Tage vorher eine Aufgabe „Qualifikation erneuern: Höhenarbeit von Anna Weber“ an, zuständig die Leitung des Betriebs; Art und Person stehen damit auch in Fristen und Aufgaben des Büros (entschieden am 01.11.2026). Den Nachweis als Datei bringt #802. Warum: Urlaub, Zeitkonto und Plantafel lesen aus der Akte, und ein Helfer ohne Telefon braucht eine Akte und Qualifikationen, obwohl er keinen Zugang hat.

• Die Kennzeichnung einer Haltbarkeitsgarantie des Herstellers (#433), nach der Feature-Gliederung v2.43 und den Tafeln aus Version 91 des Canvas: Am Artikel stehen Dauer, Hersteller und Modellkennung, alle drei oder keine (Migration 0108_article_durability), die Dauer in ganzen oder halben Jahren über zwei. Ein Angebot, dem die Mitteilung zur gesetzlichen Gewährleistung beiliegt, trägt dann je Ware eine Seite „Anlage 1“ und folgende mit der Kennzeichnung nach Anhang II der Durchführungsverordnung (EU) 2025/1960, vor der Mitteilung, und an der Position einen Verweis darauf. Gedruckt wird die Datei der Kommission in Farbe, unverändert bis auf ihre drei Felder, in 95 × 100 mm und in Inter (@fontsource/inter). Der Beleg hält die Angaben fest, die der Artikel beim Ausstellen trägt (Inhalt in Fassung 15). Warum: seit dem 27.09.2026 verlangen Art. 246 Abs. 1 Nr. 5a und Art. 246a § 1 Abs. 1 Satz 1 Nr. 11a EGBGB die Kennzeichnung, sobald der Hersteller dem Betrieb eine solche Garantie mitteilt.

• Material scannen auf der Baustelle (#263), nach der Feature-Gliederung v2.42 und den Tafeln aus Version 90 des Canvas: Neben „Material eintragen“ im Regiebericht öffnet „Material scannen“ die Kamera, die die EAN auf der Packung oder am Regal liest. Der Artikel mit dieser EAN kommt mit Bezeichnung und Einheit in „Material eintragen“, und nur die Menge bleibt einzutragen. Gesucht wird zuerst unter den Artikeln auf dem Gerät, auch ohne Netz, mit Netz dann im ganzen Katalog über den neuen Filter ean der Artikelliste, der genau diese EAN findet und keine Artikelnummer, in der sie steckt. Haben mehrere Artikel die EAN, stehen sie zur Wahl; ein Code, der keine EAN ist, und eine EAN, die kein Artikel hat, sagen das, mit „Nochmal scannen“ und „Von Hand eintragen“. Die Kamera ist die der Seriennummern und Etiketten, mit ZXing in Browsern ohne eigene Erkennung. Warum: Abschnitt 4.5 nennt die Materialentnahme per Barcode in der App, und seit DATANORM tragen die Artikel ihre EAN.

• Metall aus den Z-Sätzen von DATANORM (#782), nach der Feature-Gliederung v2.41 und den Tafeln aus Version 89 des Canvas: Ein Import liest die Z-Sätze, die Basis und Gewicht eines Metalls nennen, wie das Kupfer des zweiten Satzes und vor ihm, und kennt dafür Silber und Messing neben Kupfer und Aluminium (Migration 0107_silver_and_brass). Ein Metall, über das die Lieferung nichts sagt, bleibt, etwa ein von Hand eingetragenes Aluminium. Eine Zuschlagsstaffel der Z-Sätze übernimmt er nicht, ebenso wenig einen Z-Satz, dessen Gewicht sich auf eine andere Menge bezieht oder sein Feld füllt; dort bleibt das Kupfer, das der Artikel schon hat. Die Vorschau zählt die Artikel je Metall und die Staffeln, die nicht übernommen werden. Warum: In der Lieferung von Rexel tragen rund 6.800 Artikel Silber, 811 Aluminium und 166 Messing nur in den Z-Sätzen; Moritz hat am 31.10.2026 entschieden, erst diese Form zu lesen und die Staffel, in der die übrigen 20.620 Kupferartikel stehen, erst, wenn eine Rechnung zeigt, wie ihr Betrag gemeint ist.

• Entwürfe lassen sich löschen, im Büro und auf der Baustelle (#786), entschieden von Moritz am 30.10.2026: „Entwurf löschen“ im Kopf eines Entwurfs und leise unter einem Regiebericht auf dem Gerät, mit Rückfrage, auch ohne Netz über den Postausgang. Den eigenen Entwurf löscht, wer Belege bearbeiten darf, einen fremden nur, wer das neue Recht „Entwürfe anderer löschen“ (document.delete) hat; Inhaber und Büro haben es (Migration 0102_draft_creator), der Monteur auf Wunsch des Inhabers. Wer einen Beleg angelegt hat, steht jetzt in documents.created_by, für die vorhandenen Entwürfe aus dem Änderungsprotokoll nachgetragen. Route und Abgleich prüfen dieselbe Regel; ein festgeschriebener oder unterschriebener Beleg wird weiter nie gelöscht. Warum: ein Entwurf ist noch kein Beleg, er hat keine Nummer und hat den Betrieb nie verlassen, und GoBD Rz. 59 und 110 verlangen für eine Löschung nur, dass sie mit Löschmerker und Protokoll nachvollziehbar bleibt; bisher blieb ein verworfener Entwurf für immer in den Listen.

• Das Lager am Server (#298, erster Teil): Lagerorte des Betriebs, Lager und Fahrzeuge mit Kennzeichen, der Bestand je Artikel und Lagerort aus Bewegungen (Zugang, Umlagerung, Zählung mit Grund), Lagerplatz und Mindestbestand, ein neues Recht „Lager buchen“ für Inhaber und Büro. Ein Regiebericht nennt seinen Lagerort und bucht beim Unterschreiben jede Zeile eines Artikels, den ein Lager führt, einmal als Abgang am Auftrag ab. Unter dem Mindestbestand legt die Fristen-Engine eine Aufgabe „Nachbestellen“ an, ein Bestand unter null wird gezählt und nicht gesperrt, und jedes Gerät hält die Lagerorte und den Bestand der Fahrzeuge. Routen und Tabellen kommen als Bausteine aus dem Fundament (ADR 0011), dessen Tabellenfabrik dafür eigene Spalten an Lieferant und Lagerort und eine eigene Liste der Einheiten annimmt. Warum: Abschnitt 4.5 der Feature-Gliederung (v2.39), entschieden von Moritz am 31.10.2026; die Bildschirme kommen mit dem zweiten Teil.

• Der Lieferschein (#299), nach der Feature-Gliederung v2.40 und den Tafeln aus Version 86 des Canvas: Aus einer ausgestellten Auftragsbestätigung entsteht mit „Lieferschein erstellen“ einer, als Glied der Kette, mit ihren Positionen und Mengen. Er zeigt keine Preise; seine Positionen behalten die der Auftragsbestätigung ungesehen, und die Rechnung aus ihm stellt diese. Im Entwurf wählt das Büro unter „Material aus“ den Lagerort und ändert Mengen. Auf dem Gerät steht er am Auftrag unter „Lieferscheine“, und der Empfänger kann ihn unterschreiben, auch ohne Netz; das schreibt ihn fest und bucht seine Positionen aus dem Lagerort ab, die Nummer vergibt das Büro beim Festschreiben; unterschrieben wird nur ein Lieferschein, der an einer Auftragsbestätigung hängt, damit kein Entwurf mit geänderter Art am Recht zum Festschreiben vorbei fixiert wird. Unterschreibt niemand, schreibt das Büro ihn fest, und das bucht ab; abgebucht wird in beiden Fällen einmal (Migration 0105_delivery_note). Im PDF steht unter einem unterschriebenen „Empfangen:“ mit Name und Zeit, unter einem anderen zwei leere Linien zum Unterschreiben auf Papier. Warum: Abschnitt 4.2 kennt den Lieferschein seit Phase 0, gebaut war er nicht, und Moritz hat am 31.10.2026 entschieden, dass die Unterschrift möglich und keine Pflicht ist.

• Zwei Nachträge zum Lieferschein (#299), nach den Tafeln aus Version 88 des Canvas: Sein PDF nennt die Auftragsbestätigung, aus der er stammt, mit Nummer und Datum, und das Datum heißt dort „Lieferdatum“; dafür trägt der eingefrorene Inhalt eines Belegs ab Fassung 14 das Feld delivers, ein älterer Stand wird ohne gelesen. Unter „E-Mail-Einstellungen“ schaltet der Inhaber eigens ein, dass ein Lieferschein, den der Empfänger auf der Baustelle unterschreibt, gleich als PDF an den Kunden geht, wie es das für den Regiebericht schon gibt (delivery_note.mail_on_signature, Migration 0106_delivery_note_mail_on_signature); die Nachricht nennt, wer den Empfang unterschrieben hat, weil das nicht der Kunde sein muss. Warum: wer die Ware annimmt, prüft sie gegen die Bestellung, und Moritz hat am 31.10.2026 die Mail an den Kunden mit eigenem Schalter gewählt.

• Die Bildschirme des Lagers (#298, zweiter Teil), nach den Tafeln aus Version 84 des Canvas: im Büro „Lager“ mit allen Lagerorten, was unter dem Mindestbestand und unter null liegt, und „Neuer Lagerort“ mit Kennzeichen für ein Servicefahrzeug; ein Lagerort mit seinem Bestand, Lagerplatz und Mindestbestand je Artikel, seinen Bewegungen und den Buchungen „Zugang buchen“, „Umlagern“ und „Zählen“ mit Grund. Gebucht wird nur mit dem Recht „Lager buchen“, ohne es zeigt der Bildschirm keine Buchung an. Am Auftrag die Karte „Warenausgang“ mit dem, was seine Regieberichte abgebucht haben. Im Regiebericht auf dem Gerät wählt der Monteur unter „Material aus“ den Lagerort, und in „Material eintragen“ steht neben jedem Artikel, was das gewählte Fahrzeug davon hat, aus den Buchungen auf dem Gerät, auch ohne Netz; für ein Lager im Gebäude, dessen Buchungen auf keinem Gerät liegen, steht dort nichts. Lagerorte, Lagerort und Buchungen sind Bildschirme des Fundaments, die Wörter der Buchungen und die Rechte kommen von der Anwendung (ADR 0011). Warum: ohne Bildschirme ließ sich das Lager aus dem ersten Teil nur über die Routen buchen.

• Die Bildschirme des Imports aus DATANORM, Teil von #297, nach den Tafeln aus Version 79 des Canvas: am Lieferanten die Karte „Importe aus DATANORM“ mit den letzten Importen und „Dateien einlesen“; die Seite „Import aus DATANORM“, auf der die Dateien einer Lieferung nacheinander hochgehen, mit Fortschritt, und das Einlesen beginnt, sobald alle oben sind; die Vorschau mit ihren Zahlen, den Verkaufspreisen aus dem Aufschlag oder dem Satz, dass ohne Aufschlag keiner entsteht, einer Auswahl der Artikel, den Dateien, dem, was nicht übernommen wird, und den Einstellungen „Preise gelten ab“ und „Zeichensatz“; „Übernehmen“ mit Fortschritt und „Verwerfen“; und was ein übernommener, verworfener oder gescheiterter Import tat. Nur für Inhaber und Büro mit dem Recht, Einkaufspreise zu pflegen. Warum: bisher ließ sich ein Import nur über die Routen anstoßen; jetzt kann das Büro die Lieferung eines Großhändlers selbst einlesen und vor der Übernahme sehen, was sie ändert.

• Die Bildschirme zum Metallzuschlag, zweiter Teil von #462, nach den Tafeln aus Version 76 des Canvas: unter „Einstellungen“ in „Aufschlag auf Material“ die Karte „Metallzuschlag“, ob der Aufschlag auch auf den Zuschlag kommt, an oder aus ab einem Tag; am Lieferanten in der Karte „Aufschlag auf Material“ dasselbe für ihn und die neue Karte „Metallpreise“ mit dem Metallpreis je Metall ab einem Tag; am Artikel das Metall jedes Lieferanten unter seinem Namen, im Formular einer Verbindung der Abschnitt „Metall“ mit Basis und Gewicht für Kupfer und Aluminium, ein Satz zum Zuschlag über den Verkaufspreisen und in der Preisbildung das Wort zum Metall. An der Position im Büro steht der Metallzuschlag zwischen Einkaufspreis und Aufschlag, mit dem Metallpreis, aus dem er kommt; Aufschlag und Einzelpreis rechnen einander mit dem Zuschlag. Warum: das Büro soll den Metallpreis des Großhändlers eintragen und an jeder Position sehen, welcher Teil des Preises Metallzuschlag ist, ohne dass der Kunde mehr als den Einzelpreis sieht.

• Der Metallzuschlag eines Kabels, erster Teil von #462, hier Datenmodell, Import und Server: das Metall eines Artikels steht je Lieferant in supplier_article_metals, Metall, Basis in Euro je 100 kg und Gewicht je 1000 Einheiten, das Kupfer aus dem B-Satz von DATANORM, jedes Metall auch von Hand (PUT /articles/:id/suppliers/:linkId/metals); die Spalten copper_base_euros und copper_grams_per_thousand aus 0098, die in keiner Fassung erschienen sind, ziehen dorthin um (Migration 0101_metal_surcharge). Der Metallpreis eines Lieferanten gilt ab einem Tag und wird im Büro eingetragen (supplier_metal_prices, GET, POST und DELETE /suppliers/:id/metal-prices). Der Preis, den eine Position an ihrem Belegdatum nimmt, trägt den Zuschlag: was der Metallpreis des Hauptlieferanten an diesem Tag über der Basis liegt, für das Gewicht des Artikels, in der Auswahl eines Artikels (GET /articles?on=) wie in der Rechnung aus einem Regiebericht. Ob der Aufschlag auch auf den Zuschlag kommt, sagt die Einstellung material.markup_on_metal, ein Lieferant und ein Artikel, der engere gewinnt, voreingestellt nicht. GET /articles/:id/purchase?on= nennt das Metall mit dem Metallpreis des Tages, damit das Büro an der Position sieht, welcher Teil des Preises Metallzuschlag ist. Warum: ein Kabel aus DATANORM steht sonst um den Metallzuschlag zu billig im Angebot, beim Beispiel aus dem Issue um rund 46 %, und der Kunde soll einen Endpreis sehen, wie die Preisangabenverordnung ihn Verbrauchern schuldet.

• Die Bildschirme zum Verkaufspreis aus Einkaufspreis und Aufschlag, Teil 2b von #463, nach den Tafeln aus Version 72 des Canvas: unter „Einstellungen“ die Seite „Aufschlag auf Material“ für den Aufschlag des Betriebs, am Lieferanten die Karte „Aufschlag auf Material“ mit seinem eigenen Aufschlag und in seiner Artikelliste die Spalte „Hauptlieferant“, am Artikel über den Verkaufspreisen die Preisbildung, fest oder aus Einkaufspreis und Aufschlag, die Spalte „Entstanden aus“ und bei den Lieferanten Hauptlieferant, „Zum Hauptlieferanten“ und ihr Aufschlag. Ein Artikel, der dem Einkaufspreis folgt, bietet keinen Preis von Hand an. Dazu Teil 3: eine Position aus einem Artikel zeigt im Büro den Einkaufspreis des Hauptlieferanten am Belegdatum (GET /articles/:id/purchase?on=), den Aufschlag und den Einzelpreis; ändert man den Aufschlag, rechnet sich der Einzelpreis, ändert man den Einzelpreis, der Aufschlag. Die Position behält nur den Einzelpreis, Einkaufspreis und Aufschlag stehen so nie im Druck, in der E-Rechnung oder auf der Baustelle. Die Vorschau legt dafür 25 % für den Betrieb und 22 % für einen Großhändler an, und die Mantelleitung folgt dem Einkaufspreis. Warum: der Betrieb soll seinen Aufschlag selbst einstellen und sehen, woraus ein Verkaufspreis entstand, ohne dass ein Einkaufspreis die Hand des Büros verlässt.

• Ein Verkaufspreis, der dem Einkaufspreis folgt, rechnet sich neu, wenn sich etwas ändert, dem er folgt, zweiter Teil von #463, hier der Server: der Aufschlag des Betriebs (POST /settings/parameters), der eines Lieferanten (GET und PUT /suppliers/:id/markup), die Preisbildung eines Artikels, fest oder mit eigenem Aufschlag (PUT /articles/:id/pricing), ein anderer Hauptlieferant (PUT /articles/:id/suppliers/:linkId/main) und ein Einkaufspreis von Hand. Neu gerechnet wird ab heute, nie rückwirkend, für ein Lieferantensortiment oder den ganzen Betrieb im Hintergrund in Stücken zu 500 Artikeln (selling_price_runs, Migration 0100_selling_price_origins), und nach einem Neustart weiter. Woraus ein solcher Verkaufspreis entstand, Einkaufspreis und Aufschlag, steht in article_price_origins, beim Import wie beim Neurechnen, und die Ansicht eines Artikels zeigt es mit der Preisbildung, den Aufschlägen der Lieferanten und dem Hauptlieferanten, alles nur für Inhaber und Büro. Warum: der Verkaufspreis soll dem Einkaufspreis folgen, wie Moritz es am 28.09.2026 entschieden hat, und der ganze Katalog eines Großhändlers sind Hunderttausende Artikel, die kein Gerät warten lassen dürfen; die Herkunft liegt neben dem Verkaufspreis, weil der auf die Geräte reist und Einkaufspreis und Aufschlag nie.

• Der Verkaufspreis eines Artikels entsteht aus dem Einkaufspreis seines Hauptlieferanten und einem Aufschlag, erster Teil von #463: das Datenmodell und der Import aus DATANORM. Der Aufschlag des Betriebs ist eine Einstellung ab einem Tag (material.markup_basis_points), ein Lieferant und ein Artikel können einen eigenen haben (supplier_markups, article_markups, Migration 0099_markups), und der engere gewinnt. Hauptlieferant ist der Lieferant, der einen Artikel zuerst bringt; geht er, rückt der älteste nach, beides hält die Datenbank. Ein Import übernimmt den Listenpreis als Einkaufspreis, ein Nettopreis geht ihm vor, und schreibt für jeden Artikel, dessen Hauptlieferant er ist, den Verkaufspreis ab demselben Tag; ohne Aufschlag schreibt er keinen, und die Zusammenfassung der Vorschau sagt es. Ein Verkaufspreis von Hand macht den Preis eines Artikels fest, und Artikel, deren letzter Verkaufspreis von Hand eingetragen ist, bleiben fest. Warum: so hat es Moritz am 28.09.2026 nach dem Test mit einer echten Lieferung entschieden (Feature-Gliederung v2.37), ein Großhandel bringt nur Einkaufs- und Listenpreise. Aufschlag und Einkaufspreis reisen nicht mit dem Abgleich und liegen deshalb in eigenen Tabellen statt an Lieferant und Artikel, die auf jedem Gerät sind. Die Bildschirme und das Neurechnen nach einem geänderten Aufschlag kommen im zweiten Teil, Einkaufspreis und Aufschlag an der Position im dritten.

Geändert

• Die Anmeldung beim Netzbetreiber sagt bei einer Wallbox, ob die Mitteilung reicht oder es seine Zustimmung braucht: sie rechnet die Bemessungsleistungen der Wallboxen am Objekt zusammen und vergleicht mit 12 kVA (§ 19 Abs. 2 NAV, Regel im Paket Elektro 0.10.0). Warum: Bisher stand nur der allgemeine Satz da, und ob eine Wallbox zustimmungspflichtig ist, lässt sich aus den Daten der Anlage beantworten.

• Eine Erstprüfung nach einer Erweiterung oder Änderung kann die Frist der Anlage verkürzen (#822, Feature-Gliederung v2.55): Nennt sie eine Prüffrist und endet die früher als die Frist der letzten Prüfung der ganzen Anlage, gilt ihr Tag, für die Erinnerung wie im Prüfbericht je Objekt, der unter der Prüfung nennt, welche Erweiterung oder Änderung ihn vorgezogen hat. Ohne Prüffrist oder mit einer längeren bleibt die Frist stehen, und eine Teilprüfung vor der letzten Prüfung der ganzen Anlage zählt nicht mehr. Feld, Zeile darunter und PDF sagen, dass der Tag nur gilt, wenn die Frist der letzten Prüfung nicht früher endet. Warum: Ein erweiterter oder geänderter Teil kann früher geprüft werden müssen als der Rest der Anlage, etwa in einem Raum besonderer Art, und diese Frist ging bisher verloren.

• Konzept, Funktionsumfang und der Bericht der Prüfung der Elektroinstallation nennen die Normen, nach denen geprüft wird, statt der Marke des ZVEH (Feature-Gliederung v2.54). Warum: Die Marke ist den Innungsbetrieben vorbehalten, und OpenGewerk soll sie auch nicht als Zweck eines Berichts nennen.

• Die Kennzeichnung einer Haltbarkeitsgarantie (#433) steht als Text im Code (documents/durability-label.ts) und wird zum Drucken nicht mehr aus assets/legal gelesen; ein Test hält den Text Byte für Byte gegen die Datei der Kommission und die Datei gegen ihre Prüfsumme. Warum: CodeQL meldete mit Alert 25 (js/file-access-to-http), dass der Druck Dateiinhalt an den Renderer schickt. Eine fehlende Datei hält seitdem auch keinen Beleg mehr auf.

• Die README nennt OpenGewerk im Kopf und im ersten Satz eine Open-Source-Handwerkersoftware, self-hosted, mit CRM und ERP, zählt unter "Stand" auf, was gebaut ist, und verweist auf den Vergleich auf opengewerk.de. Warum: mit diesen Wörtern sucht, wer eine Handwerkersoftware für den eigenen Server will, und "Open Source" stand bisher nur in der Lizenz.

• Der Baustein der Qualifikationen im Fundament hängt eine Qualifikation an eine Person aus der neuen Fabrik peopleSchema statt an ein Konto (person_id statt user_id, ADR 0016, ergänzt ADR 0012). Warum: eine Person ohne Zugang hält sonst keine Qualifikation. OpenGewerk Haustechnik braucht dafür beim nächsten Anheben des Submoduls eine Migration, die je Konto mit Qualifikation eine Person anlegt.

• Die Suche im Artikelkatalog antwortet auch bei einem ganzen Großhandelssortiment schnell (#461): über eine eigene Suchtabelle mit Trigramm-Index für Nummer, Bezeichnung, EAN und die Nummern der Lieferanten, die die Trigger der Artikel und ihrer Lieferanten pflegen. Gemessen an 700.000 Artikeln braucht eine Suche jetzt 10 bis 110 ms statt 1,35 s und jede Seite der Liste rund 0,15 s, auch die letzte, statt bis zu 5,5 s; beide Sortierungen haben einen Index, aus dem eine Seite ohne Blick in die Tabelle kommt. Dieselbe Abfrage bedient die Liste im Büro, „Position aus Artikel“ und „Material eintragen“. Warum: unter Row-Level Security nimmt PostgreSQL für LIKE keinen Index, und jede Eingabe las den ganzen Katalog. Die Suchtabelle ist deshalb die einzige Tabelle ohne FORCE; die Anwendung hat kein Recht an ihr und erreicht sie nur über eine Funktion, die selbst nach dem Betrieb fragt. Entschieden von Moritz am 30.10.2026, festgehalten in ADR 0015.

• Die Feature-Gliederung (v2.40) legt den Lieferschein fest, wie Moritz es am 31.10.2026 entschieden hat (#299): einer je Auftragsbestätigung, im Büro angelegt, ohne Preise; der Empfänger kann ihn auf dem Gerät unterschreiben, muss es aber nicht, und sobald er festgeschrieben ist, bucht er sein Material aus dem gewählten Lagerort ab. Warum: Die Unterschrift war seit v2.24 Pflicht, belegt aber nur die Übergabe, und mehrere Lieferscheine aus einer Auftragsbestätigung hätten die Kette verzweigt.

• Die Feature-Gliederung (v2.39) legt das Lager fest, wie Moritz es am 31.10.2026 entschieden hat (#298): Lagerorte sind Lager und Servicefahrzeuge, der Bestand je Artikel und Lagerort entsteht aus Bewegungen, unter dem Mindestbestand bekommt das Büro eine Aufgabe, und Material im Regiebericht kommt aus einem je Bericht gewählten Lagerort und wird beim Unterschreiben einmal abgebucht; ein Bestand unter null nach dem Abgleich ist eine Warnung. Warum: Abschnitt 4.5 nannte nur Lagerbestand und Fahrzeuglager, und gebaut wird, was im Konzept steht.

• Ein Import aus DATANORM hält die Geräte nicht mehr auf (#297, Punkt 4): Artikel und Verkaufspreise, die kein Gerät hält, bekommen beim Schreiben die feste Nummer 1 des Abgleichs statt am Ende eine eigene. Ein Gerät holt sie, sobald der Artikel in seine Menge kommt, wie bisher beim Neuholen der Menge ab 0. Nummeriert werden am Ende nur noch die Zeilen der Artikel, die Geräte halten. Warum: beim Sortiment eines Großhändlers lief das Nummerieren 128 s, und so lange konnte kein Gerät des Betriebs Änderungen senden. Entschieden von Moritz am 30.10.2026, mit dem Restrisiko, dass ein Artikel, der in den Millisekunden vor dem Abschluss erstmals in einer Position steht, auf einem Gerät, das genau dann seine Menge neu holt, bis zu seiner nächsten Änderung in der alten Fassung bleibt.

• Die Feature-Gliederung (v2.37) trägt die Preisbildung ein, die Moritz am 28.09.2026 nach dem Test mit einer echten Lieferung aus DATANORM entschieden hat: der Listenpreis wird Einkaufspreis des Lieferanten, ein Nettopreis geht ihm vor; der Verkaufspreis entsteht aus dem Einkaufspreis des Hauptlieferanten und einem Aufschlag für den Betrieb, je Lieferant, je Artikel oder fest; ein Artikel mit Metallangaben bekommt den Metallzuschlag am Belegdatum in den Einzelpreis; Langtexte übernimmt ein Import nicht. Aufschlag auf Material und Metallzuschlag gehören damit zu Phase 2. Warum: bisher stand im Konzept noch der Listenpreis als Verkaufspreis, und gebaut wird, was dort steht.

• Was jemand bei einem Ansprechpartner ist (Bauleitung, Buchhaltung, Hausmeister), heißt im Formular und im Konfliktbildschirm jetzt „Funktion“, wie schon im Änderungsprotokoll (#556). Warum: „Rolle“ steht in dieser Anwendung für das, was ein Zugang darf (Inhaber, Büro, Monteur), und wer im Protokoll „Funktion: Hausmeister“ las, suchte das Feld im Formular unter einem anderen Wort.

• Die Aufgaben im Büro und auf der Baustelle zeigt jetzt die Liste des Fundaments (@opengewerk/platform-web/tasks), die Handwerkersoftware gibt nur noch die Anrede, ihr Recht task.write und den Link zum Auftrag herein (#597). Warum: Reihenfolge, „überfällig“ und die Zeile einer Aufgabe standen zweimal im Code, einmal hier und einmal im Fundament. Das HTML der Karten ist vorher und nachher gleich; nur „noch nicht übertragen“ steht jetzt in der Farbe dessen, was wartet, wie überall sonst. Das Formular für eine neue Aufgabe bleibt das eigene, weil es eine Notiz kennt.

• Ein Import aus DATANORM schreibt keinen Verkaufspreis mehr aus dem Listenpreis, der Haken „Listenpreis als Verkaufspreis übernehmen“ entfällt; er übernimmt Kupferbasis und Kupfergewicht aus dem B-Satz an die Verknüpfung von Artikel und Lieferant (Migration 0098_supplier_copper) und keine Langtexte mehr, eine Datei nur mit Langtexten liest er gar nicht (#297). Warum: so hat es Moritz am 28.09.2026 nach dem Test mit einer echten Lieferung entschieden (Feature-Gliederung v2.37); der Verkaufspreis entsteht künftig aus Einkaufspreis und Aufschlag (#463), der Metallzuschlag aus dem Kupfer (#462), und die Langtexte kamen ohne Umlaute und mitten im Wort abgeschnitten.

• Die Dateien eines Imports aus DATANORM werden über eine eigene Route gespeichert, PUT /suppliers/:supplierId/imports/files/:sha256, mit bis zu 200 MB statt der 25 MB jeder anderen Datei, unter denselben Budgets je Stunde und demselben freien Platz (#297). Warum: das ganze Sortiment eines Großhändlers hatte am 28.09.2026 gepackt 24,6 MB und wächst, eine größere Lieferung hätte sich nicht mehr hochladen lassen. Gelesen wird je Betrieb eine solche Datei zur Zeit und auf der Instanz höchstens zwei, eine weitere bekommt 429, bevor ihr Inhalt gelesen ist, weil die Budgets erst nach dem Lesen zählen (Security-Review von #777). Wer langsam sendet, hält keine Stelle: nach 30 Sekunden ohne Daten oder 10 Minuten insgesamt bricht die Route ab, und Konto und Betrieb warten danach 5 Minuten, ebenso nach einer Datei, die ihr Absender selbst abbricht.

• Ein Import aus DATANORM wird in einem eigenen Thread gelesen und mit dem Bestand verglichen, die Anwendung antwortet währenddessen weiter (#297). Warum: das Sortiment eines Großhändlers zu lesen hielt die Anwendung 5 Sekunden lang an, jede andere Anfrage wartete so lange. Der Thread bekommt die Hälfte des Heaps; reicht sie für eine Lieferung nicht, endet nur er, mit einem Satz in der Vorschau. Die Tests des Servers bauen ihn vorher, und die Vorschau baut den Server mit.

• Ein Import aus DATANORM mit Preisen und Löschsätzen allein lädt vom Bestand des Betriebs nur noch, was an den Nummern dieser Lieferung hängt: die Verbindungen des Lieferanten, ihre Artikel und deren Preise (#297, Punkt 5). Warum: bisher lud jede Lieferung den ganzen Bestand, beim Sortiment eines Großhändlers Sekunden und denselben Speicher zweimal, im Server und im Thread, der plant, auch für die Preisänderungen eines Monats. Eine Lieferung mit Artikelsätzen lädt weiter alles, weil Nummer und EAN eines neuen Artikels gegen jeden Artikel geprüft werden.

Behoben

• Die Blätter der Unterlagen für den Netzbetreiber (#306), der Förderunterlagen (#307) und der Aufforderung zur Abnahme kommen mit ihrer Fußzeile und in Barlow aus dem Renderer (#310). Warum: sheetJob brachte die Schrift nicht in die Seite, und ohne sie ließ Chromium die Fußzeile mit der Seitenzahl ganz weg; gedruckt wurde in einer Ersatzschrift.

• Wird ein Kunde oder ein Objekt entfernt, gehen seine Ansprechpartner mit, wie beim Lieferanten schon bisher (#555). Warum: sie blieben als lebende Zeilen stehen, GET /contacts lieferte sie weiter, und ein Gerät, das sie hielt, erfuhr nie, dass es sie fallen lassen soll; Namen, Telefonnummern und Adressen von Personen, die an nichts mehr hingen. Ein Trigger in der Datenbank markiert sie im selben Augenblick, damit es für jeden Weg gilt. Die Migration 0097_contacts_follow_deletion holt es für Kunden und Objekte nach, die schon vorher entfernt wurden, mit deren Zeitpunkt und der Migration als Grund im Änderungsprotokoll.

• Ein abgebrochener Auftrag bietet auf der Baustelle nicht mehr „Auftrag abschließen“ an, sondern sagt „Dieser Auftrag ist abgebrochen.“ (#735). Warum: er bleibt noch 30 Tage auf den Geräten, und seit der Abgleich eine Stornierung nicht mehr über job.progress aufheben lässt, endete ein Druck auf den Knopf als Konflikt in der Liste des Geräts.

Installieren und aktualisieren

Das Paket opengewerk-0.7.0.tar.gz enthält den Ordner opengewerk/docker. Zum Installieren entpacken, mit tar --no-same-owner -xzf opengewerk-0.7.0.tar.gz, und im Ordner opengewerk sh docker/start.sh aufrufen. Für ein Update das neue Paket genauso an dieselbe Stelle entpacken, die .env bleibt, und derselbe Befehl. Gebaut wird dabei nichts, geholt werden die Abbilder dieser Fassung, für x86_64 und ARM64:

• ghcr.io/opengewerk/opengewerk:0.7.0 (sha256:1528cbd0d895c3026679375a01b0561fd4f8515e1989684e3bbdb162b16de7c5)
• ghcr.io/opengewerk/backup:0.7.0 (sha256:3ec498cc02901c800a0bb5456f8d4453fe407cd8281514499ba12484bac50b17)

Dieselben Abbilder liegen mit denselben Digests und Signaturen auch auf Docker Hub, als opengewerk/opengewerk:0.7.0 und opengewerk/backup:0.7.0. Das Paket holt sie trotzdem aus ghcr.io, denn Docker Hub begrenzt anonyme Pulls.

Gebraucht werden Docker und Docker Compose ab 2.22. Beide Abbilder sind ohne Schlüssel über Sigstore signiert. Prüfen:

cosign verify ghcr.io/opengewerk/opengewerk:0.7.0 \
  --certificate-identity https://github.com/opengewerk/opengewerk/.github/workflows/release.yml@refs/tags/v0.7.0 \
  --certificate-oidc-issuer https://token.actions.githubusercontent.com

Das Paket ist im selben Lauf genauso signiert. Vor dem Entpacken prüfen, mit opengewerk-0.7.0.tar.gz.sigstore.json daneben:

cosign verify-blob opengewerk-0.7.0.tar.gz \
  --bundle opengewerk-0.7.0.tar.gz.sigstore.json \
  --certificate-identity https://github.com/opengewerk/opengewerk/.github/workflows/release.yml@refs/tags/v0.7.0 \
  --certificate-oidc-issuer https://token.actions.githubusercontent.com