Ich möchte das Thema nochmals anstoßen. Mittlerweile buche ich notgedrungen mit einem "anonymen Spender", wenn ein Konto als "Spendenkonto" deklariert ist und Umsätze vorkommen, die keinem konkreten Spender zuzuordnen sind und plädiere trotzdem nochmals dafür, dass bei einem "Spendenkonto" auch eine leere Eingabe wie bei den Kostenstellen möglich sein sollte.
Bei Durchlaufspenden, bei denen Spenden erfolgen, die an eine weitere Stelle weitergeleitet werden und wir die Spendenbescheinigungen erstellen, sind solche Konten als "Spendenkonto" einzurichten. Bei der Weiterleitung der gesammelten Geldern und der erforderlichen Ausbuchung des Kontos ist bei der Sollbuchung derzeit zwingend auch ein Spendereingabe erforderlich, wenn man das Konto wieder auf Null stellen möchte. Diese technisch bedingte Spenderzuordnung macht meines Erachtens aber keinen Sinn.
Alle User, die die Eingabepflicht fordern, damit keine Spende versehentlich vergessen wurden, können die Spendenkonten auswerten und nach Spender sortieren und die Buchungen ohne Spendereintrag nochmals überprüfen, ob vielleicht doch eine Spendenzuordnung vergessen wurde.
Bitte liebe CT-Entwickler überlegt euch mal, ob ggf. eine Unterscheidung zwischen Standardkonto und Spendenkonto überhaupt zwingen notwendig ist. Auch bei einem Standardkkonto könnte das Spendereingabefeld angezeigt werden und der User könnte entscheiden, ob er eine Eingabe tätigt oder das Feld leer lässt. Vorrangig wäre bereits die Abschaffung der Pflichteingabe beim Datenfeld Spender eine praxisorientierte Verbesserung des Systems

@SMon76 sehe ich auch so.

Was mir bei den Auswertungen noch fehlt sind einheitliche Kopf- und Fußzeilen mit zwingend Seitenangabe n/m.
Die ausgedruckten Blätter können durchaus mal durcheinander geraten und dann wären solche Angaben hilfreich beim wieder zusammensortierten.

Ergänzung: heute wollte jemand in unserer Gemeinde 34 Lieder für Songbeamer exportieren. Das ging über ein Event - 34 Lieder in den Ablaufplan hinzufügen und dann für Songbeamer exportieren - aber wir würden es gerne auch ohne einen Event machen können. Das wäre etwas für die gewünschte 'Sammelaktionen'

Nachdem ich mich im vergangenen Jahr zu dem Thema bereits geäußert habe, möchte ich das Thema erneut ins Gedächtnis rufen, dass beim Kontoauszugsimport bei den vorgeschlagenen Buchungen auch wiederkehrende Splitbuchungen erkannt werden müssen, da nicht nur mir dieses Thema unter den Nägeln brennt.
Die meiste Zeit bei meiner Buchungserfassung vergeude ich mit diesen Buchungen, die locker von einer Software erkannt und verarbeitet werden könnten.
So ist man gezwungen Monat für Monat solche Vorgänge entweder grundsätzlich manuell zu buchen oder generierte Buchungen nachträglich zu splitten.
Bei jeder manuellen Buchung im Folgemonat, muss man sich erst wieder überlegen, auf welche Konten, Kostenstellen mit welchen Teilbeträgen der Gesamtbetrag aufzuteilen ist und greift auf manuelle Aufzeichnungen zurück, die man immer wieder zur Hand nehmen muss.
Würden solche Buchungen maschinell erkannt werden, könnte man mit einem Bestätigungsklick die gewünschte Buchung auslösen, statt mühsam viele Eingabefelder zu bestücken.

Liebe CT-Entwickler ich lege Euch meinen Wunsch nochmals ans Herz und bitte Euch, dieses Thema bald anzugehen. Alle finanzverantwortlichen User werden es Euch danken.

@bwl21 Ich glaube, die sind noch in der Closed Beta, daher wissen nicht alle, was du meinst 😉

Bin tatsächlich auch schon dabei, Chatty für eine entsprechende Lösung zu bemühen. Bin aber noch nicht zufrieden genug zum Veröffentlichen

ChurchTools-Chat ist bewusst schlank gehalten für Personen-, Gruppen- und Event-Chats – die Funktionen sind eng mit ChurchTools verzahnt, weil eine einfache und datenschutzkonforme Lösung gewünscht war. Es gibt keinen offiziellen Anwendungsfall, der einen scalar.vector.im-Integrationsserver erfordert.
Der Chat verarbeitet Informationen nur mit Zustimmung der Nutzer, benötigt keinen Zugriff auf Kontakte, und alle Daten liegen auf Servern in Deutschland. Ein aktivierter Integrations-Manager (scalar.vector.im, betrieben von New Vector/Element in UK) würde diesem Modell widersprechen, da er Konfigurationsdaten an einen zusätzlichen, nicht von ChurchTools kontrollierten Drittserver gäbe.

@Neumeier geht in der Form nicht, was genau willst du einbinden?

@alexentz sagte in Kalender Nutzung:

Bei der Dienstplanung finde ich es aber dann wiederum Kontraproduktiv mit mehreren Kalender zu arbeiten, da manche Teams voneinander wissen sollen bzw. am selben Event dienen. Oder ist es schon zu spät und ich denke falsch? 🤗

Teams, die von einander wissen sollen, kam man mit entsprechenden Berechtigungen zu solchem Wissen verhelfen.

Wenn es aber dasselbe Event ist, steht es doch sim selben Kalender? Oder meinst Du Event nicht im ChurchTools-Sinn wie z.B.: Gemeindefest mit morgens Gottesdienst (>GoDi-Kalender, GoDi-Dienste), Mittagessen (>allg.Kalender, Küchendienst), Nachmittagsprogramm (>all.Kalender, ...), abends Abschlußkonzert (> Musik-Kalender, >Technik-Dienst)?

@simons Stimmt genau, vielen Dank für den Hinweis!

Ich antworte mir hier nochmal selbst, da die Follow-Ups für mich tatsächlich in hohem Maße an Attraktivität verlieren, wenn ich das Email-Intervall nicht einstellen kann.

Beispiel onboarding: Ich habe eine Gruppe "Erste Schritte", die Gäste beim Weg in die Gemeinde begleiten soll. Es gibt verschiedene "Meilensteine" (zu Willkommen-abend einladen, KG empfehlen, .... irgendwann über Mitgliedschaft sprechen).

Ich nutze die FUs vor allem als Erinnerung, diverse Gespräche zu führen bzw. Termine auszumachen. Dafür ist das mega gut! Aber wie oben geschrieben, brauche ich diese Erinnerung keinesfalls täglich, schon gar nicht 14 Tage vorher.

Stört das sonst niemand? Oder nutzt ihr die Follow-Ups ganz anders oder gar nicht?

Hallo @thommyb,

danke für den Semantik-Hinweis „split and update" - das war die Lösung. Ich bin noch neu bei ChurchTools und brauche noch ein paar Aha-Effekte, um eure Philosophie im Modell ganz zu verstehen.

Die Selbstkritik zur noch nicht vollständigen Doku nehme ich als sehr positiv und ehrlich wahr. Gleichzeitig seid ihr, was die Automatisierungsmöglichkeiten angeht, sehr vorbildlich und weit und habt die richtigen Weichen gestellt. Dass da immer wieder ein paar Swagger-Einträge fehlen (und immer wieder fehlen werden), ist ein Zeichen für Weiterentwicklung, nicht für Stillstand.

Für alle, die das später über die Suche finden, hier der komplette Weg, da der Endpoint aktuell nicht in der OpenAPI-Spec auftaucht:

Endpoint: POST /api/calendars/{calendarId}/appointments/{appointmentId} - also POST auf den Serien-Termin selbst (die Spec kennt auf diesem Pfad nur GET/PUT/DELETE).

Body: die Felder des herausgelösten Einzeltermins plus die Split-Parameter - analog zum dokumentierten Booking-Split (POST /bookings/{bookingId}):

{ ... "title": "…", "startDate": "2026-08-19T18:00:00Z", "endDate": "2026-08-19T19:00:00Z", "allDay": false, "description": "…", "isInternal": false, "repeatId": 0, "appointmentId": 108879, "splitDate": "2026-08-19", "splitUntilEnd": false ... }

Verifiziert (bei uns): Der Server erledigt alles atomar in einem Request - Einzeltermin wird angelegt (Response enthält die neue ID), die Exception landet in der Serie, und ein am Datum hängendes Event wird samt allen eventServices (inklusive besetzter Dienste) auf den neuen Einzeltermin umgehängt. Verhalten damit identisch zu „Nur diesen Termin ändern" in der UI. Genau das, was wir gebraucht haben.

Eine kleine Anmerkung noch: Ein GET auf die Serie unmittelbar nach dem POST kann die neue Exception noch nicht enthalten (kurzer Verzug).

Danke und viele Grüße
Darijo

@alex-muehlbauer Das fände ich auch gut. Es braucht ja nur das Feld Empfänger mit Optionen Benutzer, Leiterrollen, freie Eingabe. So könnte man sich gut über neue Nutzer in einer Gruppe informieren lassen ohne über alle Änderungen zugespamt zu werden.

Auch für uns wäre es relevant einstellen zu können, ob ein neues Mitglied einer Gruppe den ganzen Chatverlauf bekommt oder nicht.

Dieselbe Funktion wünschen wir uns auch!