Büro-Apps

Acht kleine PWAs für den Büroalltag, alle im gleichen Repo, alle einzeln als App auf dem Homescreen installierbar:

• Zeiterfassung — Zeit pro Projekt erfassen, Sync auf Nextcloud.
• Quittung — Belege fotografieren/hochladen, für Nextcloud + Banana aufbereiten.
• Wettbewerbsprogramme — Architekturwettbewerbe (JSON) hochladen und vergleichen.
• Offerten — Offerten aus Modulen zusammenstellen, Kosten berechnen, auf Nextcloud sichern.
• Adressliste — Adressen filtern, Ansichten speichern, auf Nextcloud sichern.
• Pendenzen — To-do-Liste nach Projekt und Person filterbar, auf Nextcloud sichern.
• Protokoll — Sitzungsprotokolle erfassen, PDF-Export, automatische Pendenzen.
• Timeline — Terminplanung als horizontaler Zeitbalken (Gantt-artig).

Die Startseite (index.html im Repo-Root) ist nur ein Launcher: ein App-Icon-Raster wie auf dem Smartphone-Homescreen (Icon + kurzes Label, Beschreibung nur noch als Tooltip) statt einer langen Liste mit Beschreibungstext. Jede App hat ihr eigenes manifest.json und ihren eigenen service-worker.js — man kann also entweder die Startseite installieren (Icon-Raster) oder direkt auf einer Unterseite "Zum Home-Bildschirm hinzufügen" tippen, dann landet nur diese eine App als eigenes Icon auf dem Homescreen.

Gemeinsamer Code (Nextcloud-Login, WebDAV-Zugriff, Einstellungen-Dialog, zentrale Konfiguration) liegt in shared/common.js und wird von allen Apps eingebunden. localStorage ist pro Domain (nicht pro Unterordner) gültig — einmal in irgendeiner App unter dem Zahnrad-Symbol eingerichtet, gelten Benutzername/App-Passwort automatisch auch in den anderen.

Ersteinrichtung (einmalig, für alle Apps zusammen)

1. In Nextcloud: Einstellungen → Sicherheit → App-Passwörter → neues App-Passwort erstellen (z.B. Name "Büro-App").
2. In einer der Apps (egal welche) auf das Zahnrad-Symbol tippen:
   • Benutzername: euer Nextcloud-Login
   • App-Passwort: das eben erstellte
3. "Verbindung testen" klicken, bei Erfolg "Speichern". Ab jetzt sind die Zugangsdaten in allen Apps auf diesem Gerät nutzbar.

Kein eigenes Anzeigename-Feld (mehr) — der Name, der z.B. in der Zeiterfassungs-CSV als "Person" erscheint, wird automatisch aus dem Benutzernamen abgeleitet (deriveDisplayName() in shared/common.js): bei einer E-Mail-Adresse der Teil vor dem "@", sonst der ganze Benutzername, erster Buchstabe gross (z.B. max → "Max", [email protected] → "Max").

Sicherheitshinweis: Das App-Passwort wird ausschliesslich lokal im Browser gespeichert (localStorage) und niemals ins Repo committet.

Jede Person macht das auf ihrem eigenen Gerät mit ihrem eigenen Login — jeder Account hat seinen eigenen, komplett getrennten Nextcloud-Dateibereich.

CORS-Proxy (Cloudflare Worker)

Die Managed Nextcloud bei hosting.de schickt bei Cross-Origin-Requests (Browser → Nextcloud von einer anderen Domain aus) keine Access-Control-Allow-Origin-Header — der Browser blockiert deshalb den direkten Zugriff. Deshalb sprechen alle Apps nicht direkt mit Nextcloud, sondern über einen kleinen Cloudflare Worker als Proxy (worker.js, gemeinsam für alle Apps). Der Worker läuft server-seitig, hat also kein CORS-Problem beim Weiterleiten, und ergänzt in der Antwort die fehlenden Header. Er speichert nichts — die Daten liegen weiterhin ausschliesslich auf eurer eigenen Nextcloud.

Worker deployen (einmalig, ca. 10 Minuten)

1. Kostenloses Konto auf dash.cloudflare.com erstellen (Free Plan reicht völlig, keine Kreditkarte nötig).
2. Im Dashboard: Workers & Pages → Create → Create Worker.
3. Einen Namen vergeben (z.B. zeit-proxy) → Deploy (legt erstmal einen Platzhalter an).
4. Auf Edit Code klicken, den kompletten Inhalt von worker.js einfügen, Deploy klicken.
5. Cloudflare zeigt euch jetzt eure Worker-URL, z.B. https://zeit-proxy.euer-name.workers.dev.
6. Diese URL bei PROXY_URL in shared/common.js eintragen (eine einzige Stelle, gilt für alle Apps), committen, pushen.

Falls der Worker schon läuft: Bei jeder Erweiterung der App (neue HTTP-Methode, neuer Header) muss der Code in worker.js erneut im Cloudflare-Dashboard eingefügt und deployed werden — Copy-Paste, kein CLI-Tool nötig. Aktuell braucht der Worker GET, PUT, MKCOL, PROPFIND und DELETE.

Falls hosting.de doch noch CORS aktiviert

Falls der Support meldet, dass CORS-Header für die Nextcloud-Instanz aktiviert wurden, könnten die Apps auch direkt gegen Nextcloud laufen (ohne Worker) — das wäre ein kleiner Rückbau in shared/common.js. Bis dahin ist der Worker die zuverlässigere Lösung.

Nextcloud-Ordnerstruktur

Alle App-Daten liegen zentral gebündelt unter Buero/Admin/App/, ein Unterordner pro Modul (appModuleFolderPath() in shared/common.js):

Modul	Ordner
Adressliste	Buero/Admin/App/Adressen (Ansichten in .../Adressen/Ansichten)
Offerten	Buero/Admin/App/Offerten und Rechnungen
Pendenzen	Buero/Admin/App/Pendenzen
Protokoll	Buero/Admin/App/Protokolle
Zeiterfassung	Buero/Admin/App/Zeiterfassung
Wettbewerbsprogramme	Buero/Admin/App/Wettbewerbe
Timeline	Buero/Admin/App/Timeline
Finanzplanung	Buero/Admin/App/Finanzplanung (ein File pro Jahr)
Finanzen-Stammdaten (Kontenplan/Kategorien/MwSt, vertraulich)	Buero/Admin/App/Finanzen
Zentrale Konfiguration: Mitarbeitende + Büro-Name	Buero/Admin/App/config.json
Zentrale Konfiguration: Projekte	Buero/Admin/App/projekte.txt

Ausnahme: die eigentlichen Quittungen/Rechnungsbelege (Fotos/PDFs) bleiben unter Buero/Admin/Finanzen (ausserhalb von App/) — nur die vertraulichen Stammdaten (Kontenplan/Kategorien/MwSt-Codes) liegen in App/Finanzen, siehe Abschnitt "Quittung" unten. Die Unterschriften-Bilder für den PDF-Export bleiben ebenfalls an ihrem bisherigen Ort (Buero/Admin/KLG und Rechtliches/ Unterschriften), da sie auch von anderen Workflows verwendet werden.

Mitarbeitende kommen zentral aus Buero/Admin/App/config.json, Projekte aus Buero/Admin/App/projekte.txt, siehe Abschnitt "Zentrale Konfiguration" unter "Zeiterfassung" unten.

---

Zeiterfassung

Zeit per Knopfdruck erfassen (P1 / P2 / P3 / Pause / Stop), Einträge werden automatisch als CSV auf Nextcloud synchronisiert. Läuft offline und synchronisiert, sobald wieder Netz da ist.

Funktionsweise

• Klick auf P1/P2/P3 beendet den aktuell laufenden Zähler (falls einer läuft) und startet sofort einen neuen für das geklickte Projekt.
• Klick auf Pause beendet den aktuellen Zähler, startet aber keinen neuen.
• Klick auf Stop ist identisch zu Pause (Tagesende).
• Nachtragen: Zeit für ein beliebiges (auch vergangenes) Datum manuell eintragen, falls mal vergessen wurde zu starten/stoppen.
• In der "Heute"-Liste lässt sich jeder Eintrag über das Stift-Symbol (✎) bearbeiten: Dauer und Kommentar für diesen Tag/dieses Projekt anpassen (überschreibt die bisherige Summe) oder über "Löschen" komplett entfernen (inkl. Kommentar, mit Rückfrage).
• Jeder abgeschlossene Zeitabschnitt wird als eine Zeile in eine CSV-Datei auf eurer Nextcloud geschrieben — pro Person eine eigene Datei.
• Alles läuft lokal im Browser (localStorage), auch offline. Nicht synchronisierte Einträge werden automatisch nachgeliefert, sobald Internet verfügbar ist (Retry alle 30s + sofort bei "online"-Event).

Zielordner: TARGET_FOLDER_PATH in zeiterfassung/app.js (Standard Buero/Admin/App/Zeiterfassung, siehe Abschnitt "Nextcloud-Ordnerstruktur" oben), wird bei Bedarf automatisch angelegt.

Zentrale Konfiguration (config.json + projekte.txt)

Mitarbeitende und Projekte werden zentral von der Büroleitung verwaltet, in zwei getrennten Dateien auf Nextcloud — bewusst nicht in einer gemeinsamen JSON-Datei, weil die Projektliste von beiden Personen oft bearbeitet wird und eine reine Textdatei dafür praktischer ist (kein JSON-Syntaxrisiko durch Kommas/Anführungszeichen). Alle Module laden beide über dieselbe Funktion (refreshAppConfig() in shared/common.js) — beim Start (nach dem Login), nach dem Speichern der Einstellungen sowie danach alle 60 Sekunden/beim Zurückkehren in den Tab. Ein Login (Benutzer + App-Passwort) ist dafür zwingend nötig — es gibt keinen öffentlichen, zugangsdatenfreien Lesezugriff mehr. Beide Dateien werden unabhängig voneinander geladen: ist eine (noch) nicht erreichbar, bleibt für die jeweils andere trotzdem der letzte bekannte Stand erhalten.

Buero/Admin/App/config.json — Mitarbeitende + Büro-Name:

{
  "bueroName": "Muster Architekten AG",
  "mitarbeitende": [
    { "key": "max", "name": "Max Muster", "datei": "Unterschrift_Max_Muster.png" },
    { "key": "erika", "name": "Erika Muster", "datei": "Unterschrift_Erika_Muster.png" }
  ]
}

bueroName erscheint als Titel auf der Startseite (Dashboard) sowie im Browser-Tab, anstelle des sonst fest hinterlegten "Büro" — fehlt das Feld (oder ist noch nicht eingeloggt), bleibt es beim generischen "Büro" als Fallback. key (interner Schlüssel, z.B. für Kürzel/Zuordnung), name (Anzeigename), datei (Dateiname der Unterschrift auf Nextcloud, siehe Abschnitt "Unterschriften" bei den Offerten — nur dort gebraucht, kann bei anderen Einträgen weggelassen werden).

Buero/Admin/App/projekte.txt — Projekte, ein Eintrag pro Zeile, optional mit dreistelliger Projektnummer, Leerschlag, Projekttitel (der Titel darf selbst Leerschläge enthalten; eine Zeile ohne führende Nummer ist ebenso gültig und besteht dann nur aus dem Titel):

021 Neubau Werkhof
014 Umbau Altstetten
003 Verwaltung

Zeiterfassung, Pendenzen und Timeline ordnen Einträge, filtern und weisen Farben über den Projektnamen zu, nicht über die Nummer — eine Nummer ist dort rein kosmetisch (wird beim Anzeigen aus der Zeile herausgeparst, taucht aber nirgends in der App auf) und darf durchaus mehrfach vergeben sein, z.B. für mehrere interne/nicht-projektbezogene Kategorien:

000 Büro Allgemein
000 Akquisition

"Büro Allgemein" und "Akquisition" bekommen hier trotz identischer Nummer "000" unterschiedliche Farben und werden beim Filtern korrekt auseinander- gehalten (Farbe = String-Hash des Namens, siehe stringHash() in zeiterfassung/app.js/pendenzen/app.js/zeiterfassung/dashboard/js/ dashboard.js). Einzige Einschränkung: der Name muss eindeutig sein — zwei Zeilen mit demselben Namen wären für Zeiterfassung/Pendenzen/Timeline nicht unterscheidbar. Ein Projekt umzubenennen trennt bestehende Einträge vom "neuen" Namen (kein stabiler ID-Bezug wie bei einer reinen Nummer) — dafür sind Nummern-Dopplungen (s.o.) unproblematisch, was in der Praxis öfter vorkommt als eine Umbenennung.

Protokoll und Rechnungen (bei den Offerten) hingegen wählen ein Projekt über ein Dropdown mit Nummer UND Name gemeinsam (siehe jeweiliger Abschnitt unten). Auch hier ist eine mehrfach vergebene Nummer unproblematisch: die Dropdown-Optionen selbst sind intern über ihre Position in der Liste (nicht über die Nummer) eindeutig identifizierbar, sodass sich zwei gleichnummerierte Projekte trotzdem sauber auseinanderhalten lassen — sowohl beim Auswählen als auch beim späteren Wiederöffnen eines gespeicherten Protokolls/einer Rechnung (die richtige Option bleibt vorausgewählt, nicht z.B. die erste mit derselben Nummer).

Später ändern: einfach die jeweilige Datei in Nextcloud bearbeiten und speichern — alle Geräte übernehmen die Änderung automatisch (spätestens nach 60s bzw. beim nächsten Tab-Wechsel), kein Code-Update nötig.

Datenformat

Pro Person und Jahr eine Datei (im jeweils eigenen Nextcloud-Account):

/Buero/Admin/Zeiterfassung/zeiterfassung_2026.csv

Spalten:

Datum,Projekt,Dauer_Min,Kommentar,Person
2026-08-13,Projekt Nord,105.30,Vormittag Konzept, Nachmittag Umsetzung,Max
2026-08-13,Projekt Süd,12.45,Kurzes Telefonat,Max

Es gibt eine Zeile pro Tag und Projekt, nicht eine Zeile pro Start/Stop-Wechsel — mehrere Wechsel zum selben Projekt am selben Tag werden zu einer Summe zusammengefasst. Beim Sync wird die passende Zeile gesucht und aktualisiert; nur wirklich neue Tag/Projekt-Kombinationen werden angehängt.

• Dauer_Min ist auf 2 Nachkommastellen genau.
• Kommentar lässt sich in der App unter "Heute" pro Projekt eintragen, bezieht sich auf die Tagessumme, nur für den heutigen Tag editierbar.
• Person kommt aus dem Anzeigename, der automatisch aus dem Benutzernamen abgeleitet wird (siehe "Ersteinrichtung" oben).
• Klicks unter 5 Sekunden werden ignoriert (Schutz vor Versehen-Klicks).

Auswertung (zeiterfassung/dashboard/)

Eine separate, schreibgeschützte Auswertungsseite (Charts + Tabelle nach Projekt/Person) liegt unter zeiterfassung/dashboard/ — liest die CSVs über öffentliche Nextcloud-Freigabelinks (PERSON_SOURCES in dashboard/js/dashboard.js), kein Login nötig. Von der Startseite aus über ein eigenes Icon ("Auswertung") erreichbar.

Filterbar nach Jahr, Projekt, Person sowie zusätzlich nach Zeitraum: "Ganzes Jahr" (Standard), "Heute", "Diese Woche", "Dieser Monat" oder "Frei wählbar" (zwei Datumsfelder). Die Jahres-CSV wird weiterhin komplett geladen, der Zeitraum-Filter schränkt die schon geladenen Zeilen per Datumsvergleich zusätzlich ein. "Heute"/"Diese Woche"/"Dieser Monat" beziehen sich immer auf das echte heutige Datum — weicht das vom gerade gewählten Jahr ab, wechselt die Jahresauswahl automatisch mit (sonst gäbe es scheinbar keine Treffer). Ein frei gewählter Zeitraum, der über einen Jahreswechsel hinausgeht, wird nicht unterstützt — gezeigt wird dann nur der Teil im gerade geladenen Jahr.

Charts: "Nach Projekt" (horizontale Balken, ein Balken pro Projekt) und "Nach Tag" (vertikale Balken nebeneinander, ein Balken pro Kalendertag im aktuell gefilterten Zeitraum — auch Tage ohne Eintrag, als flacher, hell eingefärbter Strich, damit Lücken im Diagramm sichtbar bleiben statt stillschweigend zu fehlen; ohne Einzelbeschriftung, stattdessen Datum+Dauer als Tooltip beim Hovern/Antippen). Fehlt beim "Zeitraum"-Filter eine explizite Eingrenzung ("Ganzes Jahr", oder "Frei wählbar" mit nur einer gesetzten Seite), wird automatisch das ganze geladene Jahr angezeigt — beim gerade laufenden Jahr nur bis heute, nicht bis Jahresende, damit keine leeren Balken für die Zukunft erscheinen. Die Balken teilen sich per CSS (flex:1 1 0) immer die volle verfügbare Breite, egal wie viele es sind (bis zu 366 bei "Ganzes Jahr") — kein horizontales Scrollen nötig, passt sich auch bei einer Fenstergrösse-Änderung von selbst neu an.

---

Quittung

Belege (Foto oder PDF) erfassen, nach Nextcloud hochladen und als Buchung für Banana vorbereiten. Die kurze Bedienungsanleitung steht nicht mehr fest auf der Seite, sondern hinter dem ?-Symbol ("Hilfe") neben Startseite/ Einstellungen oben rechts.

1. Foto aufnehmen oder Datei (Bild/PDF) auswählen.
2. Datum, Einnahme/Ausgabe, Betrag, MwSt/USt-Code, Konto und Kategorie sowie einen Verwendungszweck eingeben. Die MwSt/USt-Code-Auswahl passt sich automatisch an Einnahme/Ausgabe an (Umsatzsteuer-Codes V* bei Einnahme, Vorsteuer-Codes M*/I* bei Ausgabe), ebenso die Kategorie-Auswahl (nur Erlöse bei Einnahme, nur Aufwände bei Ausgabe).
3. Beim Speichern:
   • Zielordner ist RECEIPT_TARGET_FOLDER_PATH (Standard Buero/Admin/Finanzen in quittung/app.js) plus automatisch das aktuelle Jahr als letzte Ebene, z.B. Buero/Admin/Finanzen/2026.
   • Belegnummer-Schema: [JJ]-[A|E][NNN], z.B. 26-A003 — JJ = aktuelles Jahr (2-stellig), A/E = Ausgabe/Einnahme, NNN = dreistellig fortlaufend, getrennt gezählt pro Jahr und Typ. Die App liest den Zielordner per WebDAV (PROPFIND) und zählt weiter.
   • Fotos werden automatisch in ein PDF umgewandelt (echte PDF-Uploads bleiben unverändert) — damit landen im Ordner einheitlich nur PDFs. Die Umwandlung passiert komplett im Browser, ohne externe Bibliothek: das Foto wird auf ein <canvas> gezeichnet, als JPEG re-encodiert und roh (DCTDecode) in ein von Hand zusammengesetztes Ein-Seiten-PDF eingebettet (A4, Bild zentriert/eingepasst, Hoch- oder Querformat je nach Seitenverhältnis) — siehe imageFileToPdfBlob()/ buildSingleImagePdf() in quittung/app.js.
   • Die Datei wird als [Belegnummer] [Verwendungszweck, max. 60 Zeichen].pdf in diesen Ordner hochgeladen, z.B. 26-A003 KUARIO Quittung.pdf.
   • Zusätzlich wird die Buchung als Zeile an buchungen.txt im selben (Jahres-)Ordner angehängt.

Wichtig: Diese Funktion braucht zwingend eine Internetverbindung (die nächste Belegnummer wird live aus dem Ordnerinhalt ermittelt) — kein Offline-Modus.

Unter dem Button zeigen zwei Listen ("Letzte Ausgaben"/"Letzte Einnahmen", je Nummer/Bezeichnung) die letzten 5 bzw. 2 Belege — anhand der tatsächlich im Zielordner liegenden Belegdateien ermittelt (Dateiname [Belegnummer] [Bezeichnung].ext), nicht aus buchungen.txt (die kann z.B. nach einem Banana-Import geleert werden, während die Beleg-PDFs bleiben), neueste zuerst. Bewusst ohne Betragsspalte: der Betrag steht nur in buchungen.txt und wäre gerade für ältere Belege oft nicht (mehr) auffindbar — Nummer und Bezeichnung reichen als schneller Überblick. Aktualisiert sich nach jedem gespeicherten Beleg sowie beim Zurückkehren in die App.

Banana-Import-Format (buchungen.txt)

Banana Buchhaltung importiert kein CSV, sondern nur sein eigenes generisches Tab-getrenntes TXT-Format "Bewegungen Einnahmen-Ausgaben". Die offizielle Doku nennt die Spalten "DocInvoice"/"ContraAccount" — im tatsächlichen Import-Dialog von Banana heissen sie aber "Doc"/"Category" (im Test bestätigt, die Doku ist an der Stelle ungenau):

Date	Description	Income	Expenses	Doc	Category	Account	VatCode
2026-01-15	KUARIO Quittung		45.90	26-A003	4000	6500	M81

(Date im Format yyyy-mm-dd, Beträge mit Punkt als Dezimaltrennzeichen, kein Tausendertrennzeichen.) Die Spalten werden so befüllt:

Datei-Spalte	Quelle
Date	Datum aus dem Formular
Description	Verwendungszweck (voller Text, nicht gekürzt)
Income / Expenses	Betrag, je nachdem ob Einnahme oder Ausgabe
Doc	Belegnummer, z.B. 26-A003
Category	Kategorie/Gegenkonto
Account	Konto
VatCode	MwSt/USt-Code

buchungen.txt ist bewusst nicht direkt die Banana-Buchhaltungsdatei (deren .ac2/natives Format ist proprietär), sondern eine Warteschlange zum Import: in Banana über Datei → Import → Bewegungen importieren einlesen.

Kontenplan, Kategorien und MwSt/USt-Codes pflegen

Kontenplan, Kategorien und MwSt/USt-Codes werden nicht in quittung/app.js hart hinterlegt, sondern zur Laufzeit aus drei Textdateien geladen — unterschiedlich abgelegt, je nachdem ob sie Projekt-/Kundennamen enthalten:

• mwst.txt: reine, nicht auftragsbezogene Banana-Referenzliste der MwSt/USt-Codes — liegt im quittung/-Ordner im Repo, vom gleichen Origin wie die App selbst ausgeliefert (GitHub Pages), reicht ein einfacher fetch() (kein Nextcloud-Proxy nötig, kein CORS-Thema).
• konten.txt/kategorien.txt: die Kategorien enthalten Kontonummern mit Projekt-/Kundenbezug (z.B. Adressen laufender Aufträge als Kategorie-Bezeichnung) — liegen deshalb vertraulich auf Nextcloud unter Buero/Admin/App/Finanzen/ statt im (öffentlichen!) Repo, per Nextcloud-Proxy geladen (braucht deshalb ein Login, siehe unten). Lokal bei dir bleiben sie trotzdem als Arbeitskopie in quittung/konten.txt/ kategorien.txt bestehen (in .gitignore eingetragen, damit sie nicht versehentlich wieder committet werden).

Format (beide Fälle gleich): Tab-getrennte Zeilen Code<TAB>Bezeichnung, ein Eintrag pro Zeile — exakt der Export aus Banana (Datei → Export → Daten für Excel/Open Office/…, Tabellen "Accounts"/"Categories"/ "VatCodes", dort die Beträge-Spalten weglassen/löschen). Zeilen ohne Code (Leerzeilen, Abschnittsüberschriften, Total-Zeilen) werden beim Einlesen automatisch übersprungen; bei kategorien.txt werden die Überschriften "ERLÖSE" und "AUFWÄNDE" als Gruppen erkannt.

Ändert sich der Kontenplan in Banana:

• mwst.txt: Datei in Banana neu exportieren, Beträge-Spalten entfernen, quittung/mwst.txt ersetzen, committen und pushen — die App übernimmt die Änderung automatisch (alle 60s sowie beim Öffnen des Beleg-Formulars), ohne Code-Update.
• konten.txt/kategorien.txt: Datei in Banana neu exportieren, Beträge-Spalten entfernen, die lokale quittung/konten.txt/ kategorien.txt ersetzen (nur als eigene Arbeitskopie/Referenz) und die aktualisierte Datei direkt in Nextcloud unter Buero/Admin/App/Finanzen/ hochladen (ersetzen) — kein Commit/Push nötig, die App lädt beim nächsten Öffnen/alle 60s die Nextcloud-Version neu.

MWST_EINNAHME_CODES/MWST_AUSGABE_CODES in quittung/app.js legen fest, welche Codes aus mwst.txt überhaupt zur Auswahl stehen (aktuell nur die gültigen Sätze 0/2.6/3.8/8.1%) — das ändert sich praktisch nie und bleibt deshalb hart hinterlegt; nur die Beschreibungstexte kommen live aus mwst.txt.

Für den allerersten Start ohne Internet/Login gibt es zusätzlich FALLBACK_KONTEN/FALLBACK_KATEGORIEN/FALLBACK_MWST_CODES in quittung/app.js als Fallback (danach übernimmt der localStorage-Cache der zuletzt erfolgreich geladenen Dateien diese Rolle) — bewusst ohne die auftragsspezifischen Kategorien-Zeilen, da dieser Fallback im (öffentlichen) Quellcode steht.

Sicherheitshinweis: Ein roher Banana-Export (mit Beträgen) enthält reale Umsatz-/Aufwandszahlen pro Konto — so eine Datei niemals ins Repo committen, da dieses Repo öffentlich auf GitHub liegt (GitHub Pages braucht ein öffentliches Repo). *.jcsv-Dateien sind deshalb in .gitignore eingetragen — vor jedem Export sicherstellen, dass in konten.txt/kategorien.txt/mwst.txt wirklich nur Code und Bezeichnung stehen, keine Beträge-Spalten.

---

Wettbewerbsprogramme

Mehrere strukturierte JSON-Zusammenfassungen von Architekturwettbewerbs-Ausschreibungen hochladen, auf Nextcloud sichern (geräteübergreifend verfügbar) und tabellarisch vergleichen.

• JSON hochladen: eine oder mehrere .json-Dateien auswählen. Jede muss mindestens ein Feld projektname haben, sonst wird sie mit Fehlermeldung übersprungen. Erwartetes Schema: Felder wie auftraggeber, bausumme, groesse, termine, preisgeld, sachjury, fachjury, verfahrenssekretariat, …
• Tabelle: eine Zeile pro Wettbewerb (Projekt, Auftraggeber, Bausumme, HNF/GF, Preisgeld, Abgabetermin, Anzahl Preise). Klick auf eine Zeile öffnet die Detailansicht mit allen weiteren Feldern (Jury, Verfahrenssekretariat, Aufgabe, Experten) sowie einem Löschen-Button.
• Speicherort: Zielordner WETTBEWERB_TARGET_FOLDER_PATH (Standard Buero/Admin/App/Wettbewerbe in wettbewerbsprogramme/app.js), kein Jahresordner (Wettbewerbe sind nicht zwingend jahresgebunden). Jede Datei wird unter ihrem (bereinigten) Originaldateinamen abgelegt; erneutes Hochladen derselben Datei überschreibt die bestehende Version.
• Lokaler localStorage-Cache des zuletzt geladenen Datensatzes als Offline-Fallback; Refresh automatisch alle 60s sowie beim Zurückkehren in den Tab, oder manuell über "Aktualisieren".

Diese Funktion braucht (wie Quittung) DELETE als erlaubte HTTP-Methode im Cloudflare Worker — siehe Abschnitt "Worker deployen" oben.

---

Offerten

Offerten und Rechnungen (gleiches Formular/Datenmodell, unterschieden durch das Feld "Typ") aus einzelnen Positionen (Phasen-Überschriften und Module) zusammenstellen, beliebig hoch-/runterschieben, Zwischentotal / MWST / Total automatisch berechnen, auf Nextcloud sichern und als PDF exportieren. Offerten/Rechnungen lassen sich duplizieren, um für ähnliche Aufträge nicht alles neu erfassen zu müssen.

• Liste: alle gespeicherten Offerten/Rechnungen (Nr., Datum, Typ, Projekt, Empfänger, Total, Status), neueste zuerst, mit PDF- (📄) und Duplizieren-Button (⧉) pro Zeile. "+ Neu" öffnet den Editor leer (Typ "Offerte" vorausgewählt, im Editor umschaltbar), Klick auf eine Zeile öffnet ihn zum Bearbeiten. Die Status-Spalte ganz rechts ist als einziges Feld direkt in der Liste editierbar (Dropdown, ohne den Editor zu öffnen) und speichert die Änderung sofort auf Nextcloud.
• Status: rein interner Vermerk, taucht nicht im PDF auf — nur zur eigenen Übersicht, editierbar im Editor (vierte Spalte neben Typ/Nr./ Datum) oder direkt in der Liste. Rechnungen kennen alle drei Werte (In Bearbeitung / Versendet / Bezahlt, siehe STATUS_LABELS/ statusKeysForTyp() in offerten/app.js) — Offerten dagegen bewusst nur zwei (In Bearbeitung / Versendet, kein "Bezahlt": man bezahlt kein Angebot). Da "Versendet" bei einer Offerte damit bereits der Endzustand ist, erscheint es dort grün (wie "Bezahlt" bei Rechnungen), während es bei Rechnungen weiterhin neutral-blau bleibt (dort ist ja erst "Bezahlt" der Abschluss). Beim Umschalten des Typs im Editor bleibt eine gültige Status-Auswahl erhalten, eine bei Rechnung gesetzte "Bezahlt"-Auswahl fällt beim Wechsel zu Offerte auf "In Bearbeitung" zurück.
• Typ: Offerte oder Rechnung, jederzeit im Editor umschaltbar (gleiches Formular für beide) — "Offert-Nr." heisst dann "Rechnungs-Nr.", und im PDF erscheint unterhalb der Summen zusätzlich fix der Satz "Zahlbar innert 30 Tagen" (bewusst kein eigenes Feld dafür, kein Datum und kein IBAN/QR-Zahlteil — der wird separat übers E-Banking erstellt). Eine bestehende Offerte per Typ-Wechsel + Speichern direkt in eine Rechnung umzuwandeln, überschreibt dieselbe Datei (kein automatisches "Original behalten + neue Rechnung erzeugen") — dafür zuerst Duplizieren, dann am Duplikat den Typ auf Rechnung stellen.
• Editor — Kopfdaten: Typ, Offert-/Rechnungs-Nr. (optional, frei), Datum und Status nebeneinander in der ersten Zeile, darunter Projekt, Empfänger, Adresse, dann Stundensatz (Fr./h) und MWST-Satz (%) nebeneinander (beide ohne Zähler-Pfeile, reine Eingabefelder) — alles für diese Offerte/ Rechnung. Dazu Betreff und ein freier Brieftext fürs PDF-Anschreiben auf der ersten Seite. Der Absender-Ort fürs "Ort, Datum" in der Brief-Datumszeile kommt zentral aus absender.json (siehe unten), kein eigenes Feld pro Offerte/Rechnung. Darunter die Unterschrift(en) (siehe eigener Abschnitt unten).
• Projekt: bei Offerten zwei frei eingebbare Felder, Projektnummer (optional) und Projekt(-name) — beide unabhängig von der zentral verwalteten Projektliste, weil aus einer Offerte nicht immer ein Projekt mit eigener Nummer entsteht. Bei stattdessen ein Dropdown mit derselben zentral verwalteten Projektliste wie Zeiterfassung/ Pendenzen/Protokoll (siehe Abschnitt "Zentrale Konfiguration" oben) — eine Rechnung betrifft praktisch immer ein bereits laufendes, nummeriertes Projekt; Auswahl übernimmt Nummer und Name automatisch in dieselben (bei Rechnungen nur versteckten) Felder. Liste und PDF zeigen "Nummer – Name", sofern eine Projektnummer gesetzt ist. Verschwindet ein Projekt später aus der zentralen Liste (z.B. abgeschlossen/archiviert), bleiben bereits gespeicherte Rechnungen davon unberührt (Nummer/Name sind beim Speichern als reiner Text übernommen worden, keine Live-Verknüpfung) — beim erneuten Öffnen einer solchen Rechnung erscheint die nicht mehr aktive Nummer trotzdem als eigene, vorausgewählte Dropdown-Option ("… (nicht mehr in der Liste)"), damit es nicht aussieht, als sei das Projekt verloren gegangen, und eine unabsichtliche Neuauswahl die alten Werte nicht überschreibt.

Diese Funktion braucht (wie Quittung und Wettbewerbsprogramme) DELETE als erlaubte HTTP-Methode im Cloudflare Worker — siehe Abschnitt "Worker deployen" oben.

Absenderadresse

Enthält echte Geschäftsdaten (Name, Adresse, PLZ/Ort, Ort fürs "Ort, Datum" in der Brief-Datumszeile, Telefon, E-Mail, Website) — liegt deshalb vertraulich auf Nextcloud statt im (öffentlichen!) Repo, analog zu konten.txt/kategorien.txt bei Quittung. Bewusst nicht pro Offerte/Rechnung erfasst, da praktisch immer gleich.

Buero/Admin/App/Offerten und Rechnungen/_absender.json anlegen (im selben Ordner wie die Offerten-Dateien selbst, aber kein eigener Offerten-Datensatz — wird beim Auflisten der Offerten ausdrücklich ausgeschlossen, siehe ABSENDER_FILENAME):

{
  "name": "Muster Architekten AG",
  "adresse": "Musterstrasse 12",
  "plz_ort": "8000 Zürich",
  "ort": "Zürich",
  "telefon": "+41 44 000 00 00",
  "email": "[email protected]",
  "website": "www.muster-architekten.ch"
}

Die App lädt die Datei zur Laufzeit per Login (proxyFetch, siehe loadAbsender() in offerten/app.js) und hält den zuletzt geladenen Stand zusätzlich in localStorage als Offline-Fallback. Fehlt die Datei (noch) auf Nextcloud, bleibt der Briefkopf im PDF einfach leer, statt dass der Export fehlschlägt. Wird für den PDF-Briefkopf verwendet (absender in offerten/app.js).

Unterschriften

Wählbare Unterzeichner (Checkboxen im Editor, nach dem Brieftext, Mehrfach- auswahl möglich) kommen aus mitarbeitende in der zentralen Buero/Admin/App/config.json (siehe Abschnitt "Zentrale Konfiguration" oben) — dieselbe Liste, die auch bei den Pendenzen fürs Zuordnen/Filtern verwendet wird (eine Person einmal pflegen statt pro Modul zu duplizieren).

datei (die Unterschrift-PNG) wird nur von den Offerten verwendet, alle anderen Module ignorieren dieses Feld einfach.

Beim PDF-Export werden die PNGs der ausgewählten Personen live von Nextcloud geladen (Ordner SIGNATURE_FOLDER_PATH in offerten/pdf.js, Standard Buero/Admin/KLG und Rechtliches/Unterschriften, im Nextcloud-Konto der gerade angemeldeten Person) und auf Seite 1 unter dem Brieftext eingefügt — Bild und Name nebeneinander, an der Unterkante ausgerichtet. Damit eine Person auch die Unterschrift der anderen einfügen kann, muss die entsprechende Datei unter demselben Pfad in beide Nextcloud-Konten gelegt werden (jedes Konto ist ja komplett getrennt, siehe oben) — das ist manuell zu pflegen, es gibt keinen automatischen Abgleich. Schlägt der Abruf einer einzelnen Datei fehl (falscher Dateiname, Datei fehlt), wird das nur als Warnung nach dem Erstellen angezeigt; das PDF entsteht trotzdem, einfach ohne diese Unterschrift.

Sicherheitsüberlegung: Der Abruf läuft über denselben authentifizierten Kanal (App-Passwort) wie alle anderen Dokumente dieser App, ist also nicht unsicherer als der Rest. Das eigentliche Risiko liegt woanders: Ein Bild einer Unterschrift lässt sich, sobald es in einem verschickten PDF steckt, von praktisch jedem Empfänger wieder herauskopieren und auf andere Dokumente einfügen — das gilt für jede Stempel-/Bild-Unterschrift, unabhängig von Nextcloud oder dieser App. Für Offerten/Rechnungen ist das gängige Praxis, ersetzt aber keine rechtsverbindliche Unterschrift für Dokumente mit höheren Formanforderungen (z.B. Verträge).

PDF-Export

"PDF erstellen" (im Editor, oder 📄 pro Zeile in der Liste) erzeugt ein zweiseitiges (bzw. mehrseitiges, je nach Länge) PDF und lädt es direkt im Browser herunter:

• Seite 1 — Anschreiben: Absenderblock oben rechts, Empfänger-Adressblock links (kein wiederholter Absender darüber), Ort/Datum rechtsbündig (z.B. "Zürich, 7. September 2026", Ort kommt aus absender.json), Betreff, Brieftext (mit Zeilenumbruch = Absatz, automatischem Zeilenumbruch bei langen Zeilen), danach optional die gewählten Unterschriften (Bild + Name nebeneinander, siehe Abschnitt "Unterschriften" oben).
• Seite 2 (garantiert eigene Seite, auch bei kurzem Brief) — Offerte/ Rechnung: Titel ("OFFERTE"/"RECHNUNG"), Projekt, Empfänger, Offert-/ Rechnungs-Nr., Datum, dann die Positionsliste (Phasen als Zwischenüberschrift, Module mit Kurzbeschrieb als Bulletpoints und optionaler kursiver Bemerkung danach, Stunden/Kosten-Spalten, Nummerierung je nach Einstellung). Vor den Summen ein fixer Hinweis mit dem tatsächlich verwendeten Stundensatz dieser Offerte/Rechnung — bei Offerte "Der mittlere Stundensatz beträgt [Stundensatz] Fr. Das Honorar wird nach effektivem Zeitaufwand abgerechnet, dabei gilt der total geschätzte Stundenaufwand als Kostendach.", bei Rechnung nur der erste Satz ("Der mittlere Stundensatz beträgt [Stundensatz] Fr.", ohne Kostendach-Klausel, da bei der Rechnung bereits abgerechnet wird) — dann die Summen; bei Rechnung zusätzlich fix der Satz "Zahlbar innert 30 Tagen" darunter (kein eigenes Feld, kein IBAN/QR-Zahlteil — siehe oben). Läuft die Positionsliste über eine Seite hinaus, folgen weitere Seiten automatisch (mit wiederholtem Spaltenkopf).
• Schrift: die echten Nudica-Schnitte (fonts/Nudica-Light.otf / Nudica-Medium.otf / Nudica-LightItalic.otf für Bemerkungen, nicht die woff/woff2 fürs Web-UI), eingebettet ohne Subsetting — mit Subsetting erzeugt die verwendete Bibliothek (pdf-lib + fontkit) mit diesen Schriften eine von manchen PDF-Readern abgelehnte Einbettung.
• Technik: offerten/pdf.js (nutzt nichts aus app.js selbst — die Unterzeichner-Konfiguration wird als Parameter übergeben statt dort geladen — aber wie app.js proxyFetch/davPath/ncSegments/authHeader aus ../shared/common.js fürs Laden der Unterschriften-PNGs), gebaut mit pdf-lib + @pdf-lib/fontkit (siehe <script>-Tags in index.html, Version dort gepinnt). Läuft komplett im Browser, kein Server/Backend nötig.
• Bewusst nicht umgesetzt: die offizielle Schweizer QR-Rechnung (Zahlteil mit Swiss-QR-Code, IBAN/Referenznummer-Validierung nach den Financial-Standards) — die wird separat übers E-Banking erstellt. Falls eine bank-/Postfinance-konforme QR-Rechnung direkt aus der App gebraucht wird, ist das ein eigenes, deutlich grösseres Vorhaben.
• : Liste/Bearbeiten/Speichern funktionieren wie gewohnt offline; "PDF erstellen" braucht (zumindest beim ersten Mal pro Browser-Cache) Internet, da pdf-lib/fontkit von einem CDN geladen werden und bewusst nicht im Service-Worker vorgecacht sind (siehe Kommentar in ) — ein einzelner fehlgeschlagener Cross-Origin-Fetch soll nicht die ganze App-Shell offline unbrauchbar machen.

---

Adressliste

Firmen- und Personenadressen filtern, in benannten Ansichten speichern und auf Nextcloud sichern. Nur für den Desktop-Browser gedacht (keine mobile Breitenbeschränkung wie bei den anderen Apps) — die Tabelle ist so breit wie das Browserfenster.

• Speicherort: jeder Kontakt ist eine eigene JSON-Datei im Nextcloud-Ordner Buero/Admin/App/Adressen (wie bei den Offerten: ein File pro Datensatz statt einer grossen Liste). Diese Funktion braucht deshalb PUT, GET, PROPFIND, MKCOL und DELETE — siehe ALLOWED_METHODS in worker.js.
• Filtern: jede Spalte hat ihr eigenes Filterfeld direkt unter dem Spaltentitel (Freitext, Gross-/Kleinschreibung egal; bei Weihnachtskarte ein Alle/Ja/Nein-Dropdown). Es lässt sich also nach jeder beliebigen Kombination von Spalten gleichzeitig filtern. Kopf- und Filter-Zeile bleiben beim Scrollen sichtbar (die Tabelle hat eine eigene, auf ca. 62% der Fensterhöhe begrenzte Scroll-Fläche).
• Sortieren: auf einen Spaltentitel klicken sortiert danach (nochmals klicken kehrt die Richtung um) — funktioniert für jede Spalte.
• Spalten: welche Spalten sichtbar sind, lässt sich über die Checkboxen oberhalb der Tabelle einstellen. Die Reihenfolge der sichtbaren Spalten lässt sich direkt in der Tabelle per Drag & Drop am Spaltentitel ändern.
• Distanz-Spalte: eine reine 4-stellige Schweizer PLZ (z.B. "8000") ins Filterfeld der Spalte "Ort" eingegeben wird als Distanz-Referenz verstanden statt als Text-Suche (dort als Textfilter ohnehin nutzlos — würde nur Zeilen zeigen, deren "Ort"-Feld diese PLZ wörtlich enthält). Die Spalte "Distanz" blendet sich dadurch automatisch ein (falls noch nicht sichtbar) und zeigt für jeden Kontakt die Luftlinien-Distanz ab dieser PLZ (adressliste/plz-data.js, Koordinaten pro PLZ-Zentrum von GeoNames, CC BY 4.0); die Liste sortiert sich gleich danach (nicht auflösbare Einträge bleiben dabei immer am Ende, unabhängig von der Sortierrichtung). Die Spalte "Distanz" hat zusätzlich ihr eigenes Eingabefeld für dieselbe Referenz-PLZ — beide schreiben denselben Wert (currentView.filters.distanz, landet darum automatisch mit in gespeicherten Ansichten), blenden aber bewusst keine Zeilen aus: die Liste wird sortiert, nicht eingeschränkt. Einmal gesetzt, bleibt die Referenz-PLZ bestehen, auch wenn im "Ort"-Filter danach wieder normal nach einem Ortsnamen gesucht wird (z.B. "nur Kontakte mit 'Muster AG' im Ort, sortiert nach Distanz ab 8000") — zum Ändern/Löschen ist danach die Distanz-Spalte selbst die massgebliche Stelle. Das Feld "Ort" wird als "PLZ Ortsname" gelesen; fehlt die PLZ (ältere Einträge haben teils nur den Ortsnamen), wird der Ortsname gegen dieselbe Liste nachgeschlagen — bei mehrdeutigen Ortsnamen (z.B. gleichnamige Orte in verschiedenen Kantonen) nicht zwingend der richtige Treffer, ein bewusst in Kauf genommenes Limit dieser Heuristik. Nicht auflösbare Einträge (leeres oder unbekanntes "Ort"-Feld) zeigen "?" statt einer Distanz.
• Kategorie, Status: kommen aus einem gemeinsam verwalteten Optionen-Set (_optionen.json, im selben Nextcloud-Ordner) statt aus freiem Text — Dropdowns statt Textfelder, sowohl im Editor als auch direkt in der Tabelle (zusammen mit Kontaktperson und Weihnachtskarte lassen sich diese vier Felder ändern, ohne den Editor zu öffnen). Neue Werte lassen sich über "+ neu…" in jedem Dropdown oder über den Button "⚙ Optionen" hinzufügen; Entfernen über "⚙ Optionen" löscht nur aus der Auswahlliste, nicht aus bereits gespeicherten Kontakten mit diesem Wert. Beim allerersten Start werden die Listen automatisch aus den schon vorhandenen Kontakten befüllt. liegt im selben Ordner wie die Kontakt-Dateien und wird beim Laden der Kontaktliste ausdrücklich ausgeschlossen (-Filter in ) — sonst würde sie selbst als leerer Phantom-Kontakt mit allen Status-Werten angezeigt.

---

Pendenzen

Einfache To-do-Liste, nach Projekt und Person filterbar.

• Speicherort: anders als Offerten/Adressliste (eine Datei pro Datensatz) liegen alle Pendenzen in einer gemeinsamen Datei Buero/Admin/App/Pendenzen/pendenzen.json — bei kurzen, oft schnell angehakten/ergänzten Texten wäre eine Datei pro Pendenz nur Overhead.
• Gleichzeitige Bearbeitung: da alle Pendenzen eine Datei teilen, würde ein einfaches Überschreiben Änderungen einer anderen Person verlieren. Beim Speichern wird deshalb der aktuelle Serverstand nochmals geholt und pro Pendenz (per id) gemergt — die jeweils neuere updatedAt gewinnt, nur lokal oder nur serverseitig bekannte Pendenzen bleiben in jedem Fall erhalten. Anders als bei den Offerten (Feld-Merge) ist das ein Merge auf Ebene ganzer Listeneinträge, ohne Nachfrage-Dialog. Endgültiges Löschen (siehe unten) markiert deshalb nur geloescht:true statt den Eintrag sofort aus der Liste zu entfernen — ein Gerät mit veraltetem lokalem Stand (z.B. ein lange nicht geöffneter Tab) kennt eine echte Entfernung sonst nicht und würde die längst gelöschte Pendenz beim nächsten Speichern über die "nur lokal bekannt bleibt erhalten"-Regel wieder zurückschreiben — genau das sorgte vor der Umstellung auf Tombstones gelegentlich dafür, dass alte erledigte Pendenzen plötzlich wieder auftauchten. Als geloescht markierte Pendenzen werden überall ausgeblendet und nach 30 Tagen beim nächsten Sync endgültig aus der Datei entfernt, damit sie nicht für immer Spuren hinterlassen.
• Projekte & Farben: kommen aus derselben zentralen projekte.txt wie die Zeiterfassung, damit ein Projekt überall gleich heisst und gleich aussieht — Zuordnung/Filter/Farbe erfolgen dabei über den Projektnamen (siehe Abschnitt "Zentrale Konfiguration" oben), eine Pendenz speichert im Feld projekt also den Namen, nicht eine Nummer. Ein Klick auf einen Projekt-Button filtert die Liste; eine neue Pendenz wird automatisch dem gerade ausgewählten Projekt zugeordnet ("Alle" → Pendenz ohne Projekt). Die ganze Zeile nimmt die Projektfarbe als Hintergrund an (nicht nur ein schmaler Rand) — der Projektname steht bewusst nicht zusätzlich als Text daneben, die Farbe reicht zum Erkennen, Platzgründe. Text/Icons wechseln je nach Helligkeit der Farbe automatisch zwischen Weiss und der normalen Textfarbe (isDarkColor() in pendenzen/app.js, grobe Luma-Schwelle, keine volle WCAG-Kontrastprüfung).
• Personen: die (aktuell 2) Personen für die Personen-Filterknöpfe kommen aus mitarbeitende in derselben config.json (gemeinsam mit den Offerten, siehe Abschnitt "Unterschriften" dort — eine Person einmal pflegen statt pro Modul zu duplizieren). Ein eigenes Personen-Dropdown beim Erfassen gibt es bewusst nicht (mehr): wie beim Projekt kommt die Person rein aus dem aktiven Personen-Filter, das deckt den Bedarf schon ab. In der Zeile selbst erscheint nur das Kürzel (Initialen), der volle Name als Tooltip bzw. im Bearbeiten-Modus.

---

Protokoll

Sitzungsprotokolle (Aktennotizen) erfassen: Header (Sitzungstitel, Projekt, Datum/Zeit, Ort), Teilnehmende mit optionalem Kürzel, Hauptteil als einfache Liste aus Zwischentiteln und Stichpunkten (Struktur analog zu Phasen/Modulen bei den Offerten), PDF-Export, auf Nextcloud gesichert (ein File pro Protokoll, wie bei den Offerten).

• Speicherort: Buero/Admin/App/Protokolle, ein JSON pro Protokoll.
• Datum/Zeit vorausgefüllt: ein neues Protokoll schlägt automatisch das heutige Datum sowie "Zeit von" als aktuelle Uhrzeit vor, auf die nächstgelegenen 15 Minuten gerundet (roundedTimeNow() in protokoll/app.js) — beides lässt sich wie gewohnt anpassen.
• Projekt: Dropdown aus derselben zentralen projekte.txt wie Zeiterfassung/Pendenzen (siehe Abschnitt "Zentrale Konfiguration" oben). Anders als bei Zeiterfassung/Pendenzen (nur der Name) zeigen Auswahl, Liste und PDF hier Projektnummer UND Name ("021 – Neubau Werkhof").
• Teilnehmende & Kürzel: Büro-Personen (aus mitarbeitende in derselben config.json) lassen sich per "+ Name"-Knopf hinzufügen und bekommen ihr Kürzel automatisch (Initialen, nicht änderbar); externe Teilnehmende werden über "+ Teilnehmer/in" als freie Zeile angelegt.
• Vorschläge beim Eintippen: im Namensfeld einer neu angelegten externen Person erscheinen live Vorschläge aus den schon geladenen, früheren Protokollen (analog zur Modul-Suche bei den Offerten, bewusst keine separate Personen-Liste oder ein zusätzliches Suchfeld — Eintippen und Auswählen sind derselbe Schritt). Enter oder Tab übernimmt direkt den bestpassenden Vorschlag samt zuletzt verwendetem Kürzel; ohne Treffer bleibt der eingetippte Name einfach als neue, freie Person stehen. Bereits im aktuellen Protokoll vorhandene sowie Büro-Personen (die eigene "+ Name"-Knöpfe haben) erscheinen nicht als Vorschlag.
• Hauptteil: Zwischentitel und Stichpunkte lassen sich wie die Phasen/Module bei den Offerten per Ziehgriff neu anordnen. Ein Stichpunkt kann optional ein Kürzel einer Teilnehmerin/eines Teilnehmers zugewiesen bekommen — das markiert ihn zugleich als Pendenz (kein separates Häkchen nötig).
• Automatische Pendenzen: ist das zugewiesene Kürzel das einer Büro-Person (externe Teilnehmende lösen nichts aus), wird beim Speichern automatisch ein Eintrag in Buero/Admin/App/Pendenzen/pendenzen.json angelegt/aktualisiert (Person und Text aus dem Protokoll; als Projekt wird der reine Name des im Protokoll gewählten Projekts übernommen, nicht die Nummer — Pendenzen ordnet Projekte namensbasiert zu, siehe Abschnitt "Zentrale Konfiguration" oben). Die Pendenz-ID ist über Protokoll- und Stichpunkt-ID stabil: ein erneutes Speichern aktualisiert denselben Eintrag (Textänderungen werden übernommen), statt zu duplizieren, und ein in der Pendenzen-App bereits gesetztes Häkchen bzw. eine manuell geänderte Reihenfolge bleiben dabei erhalten. Wird das Kürzel wieder entfernt oder der Stichpunkt gelöscht, verschwindet die zugehörige, vom Protokoll selbst angelegte Pendenz auch wieder. Kein Merge mit gleichzeitigen Änderungen aus der Pendenzen-App selbst (anders als deren eigener Sync) — Protokolle werden dafür deutlich seltener gespeichert als einzelne Pendenzen bearbeitet.

---

Timeline

Terminplanung als horizontaler Zeitbalken (Gantt-artig), rein browserbasiert (kein PDF-Export). Der Ordner heisst timeline/ (das Modul hiess früher "Zeitplanung"/zeitplanung/). Unter der alten Adresse .../zeitplanung/ liegt bewusst ein minimaler Redirect-Stub (zeitplanung/index.html + eigener service-worker.js), damit bestehende Lesezeichen/Home-Bildschirm- Icons nicht ins Leere laufen, sondern automatisch nach ../timeline/ weitergeleitet werden — inkl. eigener Service-Worker-Aktualisierung, damit das auch für bereits offene alte Tabs zuverlässig funktioniert (siehe Abschnitt "Bekannte Grenzen"/registerServiceWorkerWithAutoUpdate() in shared/common.js). Die ausführliche Bedienungsanleitung steht nicht mehr fest auf der Seite, sondern hinter dem ?-Symbol ("Hilfe") neben Startseite/ Einstellungen oben rechts. Das Zeitfenster ist immer "heute bis in 2 Jahre" — rollend, kein festes Kalenderjahr; beim erneuten Öffnen verschiebt es sich also automatisch mit.

• Speicherort: EINE gemeinsame Datei Buero/Admin/App/Timeline/zeitplanung.json (wie bei den Pendenzen) statt einer Datei pro Projekt/Aufgabe.
• Zeilen von oben nach unten:

  • Mitarbeitende (aus mitarbeitende in der zentralen config.json, siehe Abschnitt "Zentrale Konfiguration" oben) — hier Ferien/Frei eintragen (Balken immer grau). Frei/Ferien-Balken entstehen bewusst nur durch Ziehen (immer mehrtägig, kein Meilenstein per Klick wie bei Aufgaben). Jeder Tag, an dem mindestens eine Person einen Balken hat, dessen Titel "ferien", "frei", "weg" oder "abwesend" enthält (als Teilstring, nicht nur exakt — erkennt also auch z.B. "Weihnachtsferien"), bekommt einen hellgrauen Streifen über alle Zeilen hinweg — je mehr Personen an diesem Tag frei haben, desto dunkler der Streifen (isFreiTitle()/renderVacationOverlay() in timeline/app.js).

    Über das 🗓-Symbol neben dem Namen lässt sich pro Person ein Wochenschema hinterlegen (an welchen Wochentagen sie regulär da ist, wahlweise "jede Woche" oder "jede 2. Woche" ab einem gewählten Ankerdatum) — die zutreffenden Tage werden in der jeweiligen Zeile grünlich markiert, gelten automatisch fürs ganze (rollende) Jahr und blenden sich an Tagen mit einem Ferien/Frei-Balken von selbst aus. Samstage/Sonntage ohne Anwesenheit sind stattdessen grau hinterlegt (ein Tag ist also immer entweder grünlich oder grau, nie beides). Ein einfacher Klick auf einen Tag in der Mitarbeiter-Zeile schaltet dessen Anwesenheit einzeln um: ein grünlich markierter Tag wird zur Ausnahme (z.B. ein einzelner freier Montag ohne eigenen Ferien-Eintrag), ein nicht markierter Tag (z.B. ein Sonntag) wird zum einzelnen Zusatztag (ein ausserordentlicher Einsatz ausserhalb des Schemas) — nochmaliges Anklicken macht das jeweils rückgängig.

  • Projekte — entweder per Dropdown aus derselben zentralen projekte.txt wie Zeiterfassung/Pendenzen (siehe Abschnitt "Zentrale Konfiguration" oben; Zuordnung/Farbe über den Namen, nicht die Nummer) oder frei benannt über das Textfeld daneben — für Vorhaben, die (noch) nicht in der offiziellen Liste stehen. Auf Klick auf den Projekttitel lässt er sich frei umbenennen (unabhängig davon, ob der neue Name in der zentralen Liste vorkommt); die Pfeile ▲▼ (erscheinen beim Überfahren der Zeile) verschieben ein Projekt in der Liste nach oben/ unten. Auf-/zuklappbar; die Projektzeile selbst zeigt dabei immer (auch zugeklappt) alle Balken/ Meilensteine ihrer Aufgaben zusammen als halbtransparente Übersicht, bewusst ohne Titeltext (reine "Strichcode"-Ansicht) — laufen mehrere Aufgaben gleichzeitig, zeichnet sich das durch die Überlagerung als dunklere Fläche ab.

---

Finanzplanung

Liquiditätsplanung pro Kalenderjahr (fest, nicht rollend wie die Timeline) — Anfangssaldo, monatlich wiederkehrende und einmalige Ausgaben, Einnahmen, Auszahlungen (Gewinnausschüttungen an die Gesellschafter), daraus laufend berechnet der Saldo pro Monat.

• Speicherort: ein Jahr = eine eigene JSON-Datei auf Nextcloud (Buero/Admin/App/Finanzplanung/<Jahr>.json) — ein Jahr ist in sich geschlossen, beim Jahreswechsel wird ohnehin komplett neu geladen, keine Merge-Logik über Jahre hinweg nötig (anders als bei den Pendenzen).
• Jahres-Navigation: ‹ Jahr › oben, freie Navigation in beide Richtungen ohne Begrenzung.
• Drei Abschnitte (von oben nach unten): Ausgaben, Einnahmen, Auszahlungen (Gewinnausschüttungen). Beträge werden immer positiv eingegeben — ob ein Betrag den Saldo erhöht oder verringert, ergibt sich allein aus dem Abschnitt, nicht aus einem Vorzeichen (SECTIONS in finanzplanung/app.js).
  • Ausgaben und Auszahlungen fassen beide Zeilentypen bewusst in EINER Liste mit einer einzigen Summe zusammen (übersichtlicher als zwei getrennte Abschnitte), unterscheidbar am Icon vor der Bezeichnung:
    • 🔁 monatlich ("+ monatlich"): ein Betrag pro Zeile, gilt für alle 12 Monate gleich — Klick auf eine beliebige Monatszelle öffnet ein Eingabefeld, das den Betrag für die ganze Zeile ändert.
    • 📌 einmalig ("+ einmalig"): Betrag an einzelnen Monaten. Klick auf eine Monatszelle öffnet direkt ein Eingabefeld für genau diesen einen Monat (0 oder leer entfernt den Eintrag) — kein Markieren mehrerer Zellen nötig.
  • Einnahmen sind immer vom Typ "einmalig" (bei einem Architekturbüro erfahrungsgemäss nie monatlich wiederkehrend) — eigener "+ Zeile"-Knopf statt der beiden Knöpfe bei Ausgaben/Auszahlungen. Zusätzlich lässt sich zu jedem Monatsbetrag eine kurze Info hinterlegen (z.B. "Bauprojekt", "Vorprojekt", um z.B. mehrere Phasen desselben Projekts auseinanderzuhalten) — nach Eingabe des Betrags fragt ein zweites prompt()-Fenster danach (leer lassen = keine Info). Erscheint als Tooltip beim Überfahren der Zahl, zusätzlich per gepunkteter Unterstreichung auch ohne Hover erkennbar.
  • Titel UND Summe (Monats-Subtotale sowie "Total"-Spalte mit der Jahressumme) stehen gemeinsam in der OBERSTEN Zeile jedes Abschnitts — keine separate Summen-Zeile am Ende, man sieht die Zahlen sofort ohne an den Zeilen vorbeizuscrollen. Darunter die einzelnen Zeilen, danach die "+"-Knöpfe.
  • Zeilen bearbeiten: auf die Bezeichnung klicken benennt sie um; ▲▼ verschieben eine Zeile innerhalb ihres Abschnitts nach oben/unten (am Rand deaktiviert); × löscht sie (mit Rückfrage).
• Saldo-Zeile ganz unten: wird laufend für jeden Monat berechnet (berechneSalden()), rötlich eingefärbt bei negativem Saldo.
• Jahres-Übertrag: öffnet man ein Jahr, für das noch keine Datei existiert, wird der Anfangssaldo mit dem berechneten Endsaldo des Vorjahres vorbefüllt (nur falls dessen Datei existiert) — bleibt aber ein ganz normales editierbares Feld, falls die effektiven Finanzen leicht von der Prognose abweichen.

---

Bekannte Grenzen

• Kein Konflikt-Schutz bei Gleichzeitigkeit: Falls dieselbe Person eine App auf zwei Geräten gleichzeitig nutzt, kann beim Sync ein Eintrag verloren gehen (read-modify-write ohne Locking). Bei normalem Gebrauch (ein Gerät) ist das kein Thema. Ausnahmen: die Adressliste hat eine einfache Konflikt-Erkennung pro Kontakt eingebaut (siehe Abschnitt "Adressliste"), die Offerten mergen beim Speichern pro Feld (siehe Abschnitt "Offerten"), und die Pendenzen mergen ihre gemeinsame Liste pro Eintrag (siehe Abschnitt "Pendenzen").
• Läuft die Zeiterfassung über Stunden im Hintergrund/Tab geschlossen, wird der Zähler beim nächsten Öffnen korrekt weitergerechnet (kein Datenverlust), aber es gibt keine Push-Erinnerung, falls vergessen wird, auf Stop zu klicken.
• App-Icons: liegen unter icons/home-*.png, icons/zeiterfassung-*.png, icons/quittung-*.png, icons/wettbewerb-*.png, icons/offerten-*.png, icons/adressliste-*.png, icons/pendenzen-*.png, icons/protokoll-*.png, icons/timeline-*.png, icons/finanzplanung-*.png (je 192px + 512px PNG). Zum Ändern einfach unter denselben Dateinamen ersetzen — keine Code-/Manifest-Änderung nötig.

Lokal testen

python3 -m http.server 8080
# im Browser: http://localhost:8080 (Startseite)
# bzw. http://localhost:8080/zeiterfassung/, /quittung/, /wettbewerbsprogramme/,
# /offerten/, /adressliste/, /pendenzen/, /protokoll/, /timeline/

Auf GitHub veröffentlichen (GitHub Pages)

git init
git add .
git commit -m "Initial commit"
git branch -M main
git remote add origin https://github.com/<dein-user>/zeiterfassung.git
git push -u origin main

Danach im Repository unter Settings → Pages:

• Source: "Deploy from a branch"
• Branch: main, Ordner / (root)

Nach 1–2 Minuten erreichbar unter https://<dein-user>.github.io/zeiterfassung/.

Als eigene Apps installieren: Auf dem Handy die gewünschte Unterseite öffnen (.../zeiterfassung/, .../quittung/ oder .../wettbewerbsprogramme/) und dort "Zum Home-Bildschirm hinzufügen" — jede landet als eigenes Icon mit eigenem Namen. Die Startseite (.../ ohne Unterordner) lässt sich zusätzlich/alternativ als Kachel-Menü installieren.

Falls vorher schon die alte (kombinierte) Version installiert war: Das bestehende Homescreen-Icon zeigt nach diesem Update auf die neue Startseite statt direkt auf die Zeiterfassung, da Root jetzt der Launcher ist — altes Icon löschen und die gewünschten Apps wie oben neu hinzufügen.