Der Musikverein Spiez ist der erste echte Interessent. Mitglieder und Buchhaltung führte er in INSIME. Am 2026-10-13 hat die Session cluhu-5 die INSIME-Exporte (Adressen rund 560 Zeilen, 62 Artikel, 654 Buchungszeilen) per Script in den Mandanten musikverein-spiez geladen und am selben Tag Gruppen, Termine, Spesen, Revisoren und Ordner ergänzt. Der Verein testet mit sechs Personen. Die öffentliche Webseite dazu beschreibt der Webseiten-Builder unter «Vorzeigeprojekt».
- Dubletten: Eine Person privat und dieselbe Person als Firmenkontakt wird eine Person; die Firma bekommt sie als Kontakt (6 Paare).
- Paare an gleicher Adresse: zwei Mitgliedschaften mit je eigenem Beitrag; geteilt ist nur die Adresse.
- Zeilen mit zwei Vornamen: eine Mitgliedschaft, zwei Personen (16 Fälle).
- Ehemalige: 145 als ausgetreten ohne Datum.
- Flags nicht interpretieren: Anrede, Briefanrede, Register, Instrument als Dropdown mit Originalwerten; Heft, MVS, Rechnung per Post/Mail als Checkbox.
- Beiträge: Aktiv 120, Passiv 20, Ehrenmitglieder und Ehemalige 0 (Annahme, passt zu den Zahlungen; nicht vom Verein bestätigt).
- Keine erfundenen Strukturen: nur Gruppen aus INSIME (Vorstand, Musikkommission, Korps mit fünf Registern, Tambouren, Kleinformation, Aushilfen). Zwei erfundene Gruppen wurden auf Wunsch entfernt. Bemerkungen ohne technische Reste.
- Mailmaskierung: Alle Adressen wurden zu
lokal@domain.cluhu.test umgeschrieben, ausser bei den Testern und dem Betreiber. Die Domain ist mandantenübergreifend gesperrt (v0.28.42, siehe System-Mails). Seit 2026-10-14 sind alle Testmandanten gleich maskiert.
- Testlogins: Admin, drei Sekretariats-Logins und ein Dirigent (neue Vorlage
dirigent) für CluCore; zwei Revisoren fürs Portal. Angelegt zunächst ohne Einladungsversand; die Einladungen «Passwort setzen» gingen am 2026-10-15 an fünf Tester (der Kassier hatte bereits ein Login). Der Betreiber hat eine eigene Admin-Person ohne Testrollen mit separatem Login, damit sein Hauptlogin eindeutig bleibt.
- Buchhaltung: Geschäftsjahr 2026 offen, Eröffnungsbilanz per 01.01.2026 aus den INSIME-Eröffnungsbuchungen (Verlust 2025 ins Vereinsvermögen), 634 Buchungen Januar bis August. Umschlüsselung INSIME → KMU-Kontenrahmen über eine Mapping-Tabelle im Script; 23 neue Konten (Banken, TWINT als PSP-Konto, Anlagen, Fonds als Eigenkapital, Erträge für Passivbeiträge, Lokalanteile, Inserate). Kostenstellen aus den Kommissionen des Vereins. Keine Bankverbindung, kein Rechnungsabsender: die IBAN ist nicht bekannt.
- Ausbau: Leitungen mit Gruppenbezug, 107 Termine (drei Serien, 17 Einzeltermine), Spesen mit zwei Freigabe-Personen auf Stufe 1, 17 Ordner mit Freigaben.
- Script statt Import-Wizard: Der Wizard macht nur den Erst-Import von Mitgliedern. Firmen-Dubletten, Buchhaltung und Konten-Umschlüsselung brauchen Regeln, die im Script dokumentiert und wiederholbar sind (Einschätzung; die Migration hat keinen Changelog-Eintrag, nur die Session-Notiz).
- Totale Maskierung plus Sperre: Die Adressen bleiben formal gültig, damit die Oberfläche normal funktioniert; die Sperre im Backend garantiert, dass kein Code-Pfad eine echte Mail auslöst.
- Nichts erfinden: Der Verein soll seine Daten wiedererkennen. Fremde Testdaten verfälschen den Eindruck.
- Echte Daten zeigen Lücken: 22 Passivmitglieder zahlen mehr als den Beitrag → Überzahlungs-Popup (v0.28.42, siehe Faktura). Rechnungen waren über das Bündel in der Buchhaltung unsichtbar → Fix v0.28.30.
- Parallele Sessions vergeben dieselbe Versionsnummer (v0.28.41/42 kollidierten zweimal; Code-Kommentare tragen noch v0.28.41). Vor jedem Commit die Top-Version in
main prüfen.
- Nebenbefund (Session layout, v0.28.51): Testdaten im Mandanten
musiktest verwiesen ungescoped auf Personen aus Spiez. Testdaten-Scripts müssen Regel S1 einhalten.
Letzter INSIME-Export per Stichtag (September bis Dezember) und offene Rechnungen; IBANs und camt-Fähigkeit; Eintrittsjahre für eine Jubiläumsliste (Feature fehlt); Jugendmusik mit eigener Buchhaltung (eher eigener Mandant); Rolle für eine weitere Person; Artikel-Kontierung prüfen.