Referenz

Einstieg (handgeschrieben)

Dieser Abschnitt ist der einzige handgeschriebene Teil von docs/cli.md. Er lebt in Implementation/packages/cli/docs/cli-intro.md; die Kommando-Übersicht und alle Kommando-Abschnitte darunter werden aus dem Register packages/cli/src/casa/commands.ts generiert.

Die casa-CLI ist die Automations-Oberfläche derselben API, die auch das Web-UI fährt (ADR-10: API und CLI rufen dieselben Tool-Funktionen — die CLI trägt keine eigene Fachlogik). Jedes Kommando ist eine dünne Bindung an genau einen Endpunkt der OpenAPI-Spec; die API-Referenz dazu steht in api.md.

Aufruf

pnpm --filter casa_software24 casa [--profile <local|prod|…>] <kommando> [<argumente>] [--data '<json>']

Profile und Basis-URL

Profil	Basis-URL
local	http://localhost:3000 (eingebauter Default)
prod	kein eingebauter Wert — muss in der Config stehen (fail-closed)

Die Config-Datei liegt außerhalb des Repos: $CASA_CONFIG, sonst $XDG_CONFIG_HOME/casa/config.json, sonst ~/.config/casa/config.json. Sie nennt nur Basis-URLs und den Namen der Token-Env-Variable — nie einen Token.

Token

Der Bearer-Token kommt ausschließlich aus einer Umgebungsvariable: CASA_TOKEN oder die profil-spezifische tokenEnv. Kommandos mit „Token nötig: ja" brechen ohne Token fail-closed ab, statt einen anonymen Aufruf zu wagen.

export CASA_TOKEN='<session-token>'
pnpm --filter casa_software24 casa auth check

Ausgabe

Jeder Lauf schreibt genau EINEN JSON-Umschlag nach stdout (ok, command, profile, data bzw. error, exitCode) — maschinenlesbar, auch im Fehlerfall.

Schreibende Kommandos

--data '<json>' übergibt den Request-Body. --idempotency-key <key> macht einen Schreibaufruf wiederholungssicher (gleicher Key ⇒ der Server führt genau einmal aus) — der Retry-Pfad für create.

Flow-Kommandos

Die meisten Kommandos binden an genau einen Endpunkt. Ein _Flow_ (aktuell nur casa onboarding, Issue #371) fährt stattdessen eine Sequenz bestehender Kommandos — er legt keinen zweiten Schreibpfad an, sondern ruft dieselben Endpunkte in Fremdschlüssel-Reihenfolge auf und schließt mit dem Plausi-Gate objekt check. Ausgabe ist ein JSON-Protokoll (data): welcher Schritt welche Entität mit welcher Id angelegt hat, was übersprungen wurde, und das Ergebnis des Gates.

pnpm --filter casa_software24 casa onboarding --file plan.json --protokoll lauf.json

• Eingabe: --file <plan.json> — oder, ohne das Flag, interaktiv (die

Fragen gehen auf stderr, stdout bleibt allein dem JSON-Umschlag vorbehalten). Eine vollständige Beispieldatei liegt neben dieser Einleitung: packages/cli/docs/onboarding-beispiel.json.

• Wiederholbar: Das Pflichtfeld runKey ist die Identität des Vorgangs. Jeder

Schritt sendet Idempotency-Key: <runKey>:<schritt> (Schrittname = Position im Plan, nie ein Feldwert) — ein abgebrochener Lauf legt beim erneuten Start nichts doppelt an, auch ohne Protokolldatei. Weil der Schrittname die Position im Plan ist, bindet ein runKey an die Reihenfolge des Plans: Anhängen am Ende ist unproblematisch, für eine Einfügung mitten in eine Liste (Einheiten, Verträge) einen neuen runKey verwenden.

• Wiederaufsetzbar: --protokoll <pfad> wird nach jedem Schritt

geschrieben und ist eine Fortschrittsanzeige, keine Ausführungsautorität: ein zweiter Lauf fährt auch die dort als erledigt verzeichneten Schritte mit demselben Aufrufer-Key beim Server nach (das legt nichts an) und übernimmt dessen Ids. Ein Protokoll mit fremdem runKey wird ignoriert; ein verändertes (unbekannter Schrittname, fremder Key, gebrochene Einträge) oder ein zum Bestand unpassendes Protokoll bricht den Lauf ab, statt Fortschritt zu behaupten. --protokoll verlangt eine Laufzeit, die Dateien lesen und schreiben kann.

• Rote Ampel: Ein rotes Plausi-Gate ist kein Erfolg: Exit 9 (gate),

ok: false. Das vollständige Protokoll steht trotzdem unter data, die Befunde unter data.plausi.befunde. Automation darf allein am Exit-Code verzweigen. **gelb ist bewusst Exit 0** — nur rot blockt; gelbe Befunde sind Review-Aufwand und stehen im Protokoll. Eine Gate-Antwort ohne lesbare Ampel (Pflichtfeld der Route) ist ein Vertragsbruch und endet mit Exit 8 (protocol): ein unlesbares Urteil ist kein grünes Gate.

Exit-Codes

Code	Bedeutung	Code	Bedeutung
0	ok	5	NotFound
1	generisch	6	Netz
2	Bedienung	7	Server
3	Config	8	Protokoll
4	Auth	9	Gate rot

Der generische Exit 1 ist der Catch-all für fachliche Ablehnungen ohne eigenen Code — insbesondere jeden 409 (conflict). Er ist ausdrücklich kein Serverfehler: ein Retry hilft nicht. Automation, die 409 von anderen generischen Fehlern unterscheiden muss, liest error.code aus dem JSON-Umschlag; der Exit-Code allein trägt diese Unterscheidung heute nicht.

Lokale Kommandos

Diese Kommandos binden an KEINEN API-Endpunkt und tauchen deshalb in der Endpunkt-Übersicht weiter unten nicht auf. auth login ist der Einstieg: ohne Token brechen alle Kommandos mit „Token nötig: ja" fail-closed ab.

Kommando	Optionen	Zweck
auth login	--email, --password-stdin, --store, --no-browser, --frisch, --wiederherstellungscode	Meldet sich im Browser an (oder per E-Mail/Passwort) und legt den Session-Token sicher ab (Schlüsselbund).
auth logout	--store	Entfernt den abgelegten Session-Token des Profils.
completion <shell>	—	Gibt ein Shell-Completion-Skript aus (bash\	zsh\	fish).
ai install	--dir	Legt das Skill-/Instruktions-Paket für KI-Agenten an (erzeugt aus der Kommando-Referenz dieser CLI).
ai hint <state>	—	Schaltet den KI-Hinweis nach dem Login dauerhaft ab (off) oder wieder an (on).

casa auth login

Meldet sich im Browser an (oder per E-Mail/Passwort) und legt den Session-Token sicher ab (Schlüsselbund).

casa auth login [--email] [--password-stdin] [--store] [--no-browser] [--frisch] [--wiederherstellungscode]

• Optionen: --email, --password-stdin, --store, --no-browser, --frisch, --wiederherstellungscode

casa auth logout

Entfernt den abgelegten Session-Token des Profils.

casa auth logout [--store]

• Optionen: --store

casa completion

Gibt ein Shell-Completion-Skript aus (bash\|zsh\|fish).

casa completion <shell>

• Argumente: <shell> (exakte Stelligkeit — zu viele sind ebenfalls ein Bedienfehler)
• Optionen: keine

casa ai install

Legt das Skill-/Instruktions-Paket für KI-Agenten an (erzeugt aus der Kommando-Referenz dieser CLI).

casa ai install [--dir]

• Optionen: --dir

casa ai hint

Schaltet den KI-Hinweis nach dem Login dauerhaft ab (off) oder wieder an (on).

casa ai hint <state>

• Argumente: <state> (exakte Stelligkeit — zu viele sind ebenfalls ein Bedienfehler)
• Optionen: keine

Kommando-Übersicht

Kommando	HTTP	Endpunkt	Token	Zweck
auth check	GET	/api/me	ja	Prüft den Token gegen GET /api/me (Tenant + User).
beleg upload <datei>	POST	/api/beleg	ja	Reicht einen Beleg über die echte Ingest-Vordertür ein (multipart/form-data). Antwort trägt documentId + outcome.
auswertung saldenliste	GET	/api/auswertung/saldenliste	ja	Summen- und Saldenliste der Sachkonten EINES Objekts: je Konto Anfangsbestand, Soll- und Haben-Umsatz des Zeitraums und Endsaldo, gegliedert nach Kontenklassen mit Zwischensummen. Pflicht: --objekt <uuid> --von JJJJ-MM-TT --bis JJJJ-MM-TT. Optional --nurBewegt true (nur Konten mit mindestens einer Buchung IM Zeitraum; Konten mit Vortrag, aber ohne Bewegung entfallen dann ebenfalls — "gefilterteKonten" nennt ihre Zahl) und --format csv (Ausgabe ist dann die CSV-Datei auf stdout statt des JSON-Umschlags; Semikolon, Dezimalkomma, UTF-8 mit BOM — von deutschem Excel ohne Nacharbeit lesbar). Alle Cent-Felder sind Integer-STRINGS: eine Jahressumme überschreitet 2^53, als JSON-number verlöre sie Cents. Der Zeitraum ist PFLICHT — ohne "von" wäre jeder Anfangsbestand null.
auswertung katalog	GET	/api/auswertungen	ja	Listet die verfügbaren Auswertungen: Name, Titel, Zweck, Zeitbezug und Spalten. Der Name aus dieser Liste ist das Argument von "auswertung abrufen".
auswertung abrufen <auswertung>	GET	/api/auswertungen/{auswertung}	ja	Ruft EINE Auswertung des Katalogs ab (Name aus "auswertung katalog"). Pflicht: --objekt <uuid> --von JJJJ-MM-TT --bis JJJJ-MM-TT. Optional --format csv (Ausgabe ist dann die CSV-Datei auf stdout statt des JSON-Umschlags; Semikolon, Dezimalkomma, UTF-8 mit BOM, und oben die Quellenangabe: Mandant, Objekt, Zeitraum, letzte berücksichtigte Buchung). Je nach Auswertung zusätzlich --stichtag (offene Posten), --nurBewegt true (Saldenliste), --konto/--beleg (Buchungsliste), --menge offen\	alle (offene Posten), --einheit/--eigentuemer/--abschlusslauf <uuid> (hausgeld-steuerzuarbeit: Einheit oder Eigentümer UND festgeschriebener Abschluss-Lauf; fremder oder unbekannter Lauf ⇒ not_found, nicht festgeschriebener oder stornierter ⇒ conflict, ohne --einheit leer); ein Filter, den die gewählte Auswertung nicht führt, ist ein benannter Bedienfehler statt eines still verworfenen Flags. Im JSON ist jede Zelle ein String: "spalten[i].typ" sagt, wie sie zu lesen ist (betrag = Integer-Cents, weil eine Jahressumme 2^53 überschreitet).
auswertung finanzstatus	GET	/api/auswertung/finanzstatus	ja	Finanzstatus EINES Objekts. Pflicht: --objekt <uuid> UND genau einer der beiden Modi — --von JJJJ-MM-TT --bis JJJJ-MM-TT (Entwicklung der Geldkonten im Zeitraum: je Bank-/Kassen-/Rücklagenkonto Anfangsbestand, Zugänge, Abgänge, Endbestand und die Bewegungen mit laufendem Saldo NACH WERTSTELLUNG, dazu die Vermögensübersicht zum "bis"-Tag) ODER --stichtag JJJJ-MM-TT (nur die Vermögensübersicht: Geldkonten, offene Forderungen, offene Verbindlichkeiten, Reinvermögen). Beides zusammen oder keins von beidem ist 400 — ohne Zeitraum gäbe es keinen Anfangsbestand und damit keine Entwicklung. Alle Cent-Felder sind Integer-STRINGS: ein Jahresumsatz überschreitet 2^53, als JSON-number verlöre er Cents. "stimmt" (je Konto: Anfangsbestand + Zugänge − Abgänge = Endbestand) und "bilanzgleichgewicht" (Reinvermögen + Σ Sachkonten = 0) werden AUSGEWIESEN, nicht erzwungen — eine Schieflage soll sichtbar sein, nicht die Antwort verhindern.
sondereigentumsverwaltung stand	GET	/api/sondereigentumsverwaltung/stand	ja	Monatsstand der Sondereigentumsverwaltung EINES Objekts. Pflicht: --objekt <uuid> UND --monat JJJJ-MM. Je SEV-Wohnung: Stand der fünf Pflicht-Schritte (Mietgutschrift → Vergütung → Hausgeld → Sonderrücklage → Auszahlung), Saldo des Eigentümers, Sockelbetrag, Sonderrücklage, Unterdeckungen mit Betrag und der nächste fällige Schritt. Wohnung und Eigentümer stehen mit Namen da, nicht als Kennung. Ein Wert ohne Quelle steht auf "nicht verfügbar" — NIE auf 0 und nie auf "erledigt"; vollstaendig: false sagt es für die ganze Antwort. Solange die SEV-Kette nicht eingerichtet ist, ist "wohnungen" LEER und der Grund steht in "hinweise" — das ist ausdrücklich nicht die Aussage "dieses Objekt hat keine SEV-Wohnungen". Cent-Felder sind Integer-STRINGS oder null, nie JSON-numbers.
honorar berechnen	GET	/api/honorar/vorschau	ja	Verwalterhonorar EINES Objekts für EINEN Monat als Vorschau — Positionsaufstellung je Einheit, Basis und Zuschlag, dazu Netto, Umsatzsteuer und Brutto. Pflicht: --objekt <uuid> --monat JJJJ-MM. Gerechnet wird mit der Zeitscheibe der Honorarvereinbarung, die den ANGEFRAGTEN Monat abdeckt: ändert sich der Satz zum 1. Juli, gilt für Juni der alte und für Juli der neue. Alle Cent-Felder und der USt-Satz sind Integer-STRINGS, nie JSON-numbers. BUCHT NICHTS — die Ausgabe ist eine Vorschau, keine Forderung; die Sollstellung des Honorars ist ein eigener Schritt mit eigener Freigabe. Die Vereinbarung selbst wird als Objekt-Option hinterlegt: casa option set --data '{"scopeType":"objekt","scopeId":"<objekt>","key":"verwalterhonorar.vereinbarungen","value":[ <Zeitscheiben> ]}' — Wert ist eine LISTE von Zeitscheiben (gueltigAb/gueltigBis inklusive, berechnungsart, pauschaleJeEinheitentyp, satzBasispunkte, mindestbetrag, hoechstbetrag, leerstandMindestbetrag, zuschlaege, umsatzsteuersatzProzent); Beträge als {"cents":"2500","currency":"EUR"}, Sätze als Integer-Strings.
zaehler list	GET	/api/zaehler	ja	Listet die Zähler des Mandanten mit Einheitsnummer, Zählerart, Maßeinheit und Archivstand. Optional --objekt <uuid> --einheit <uuid> --zaehlerart <art> --archiveScope aktiv\	archiviert\	alle (Default aktiv). Ein fremdes oder unbekanntes Objekt ist not_found, keine leere Liste.
zaehler ablesungen <id>	GET	/api/zaehler/{id}/ablesungen	ja	Ablesungs-Historie EINES Zählers (Positional <id>), aufsteigend nach Ablesezeitpunkt. Optional --von JJJJ-MM-TT --bis JJJJ-MM-TT (beide inklusiv). Zählerstände sind Dezimal-STRINGS mit Punkt und Skala 3 (z. B. "161.700"), nie JSON-numbers. Ein unbekannter oder fremder Zähler ist not_found.
zaehler verbrauch	GET	/api/zaehler/verbrauch	ja	Verbrauch der Zähler EINES Objekts für einen Zeitraum, je Zähler und je (Einheit, Zählerart). Pflicht: --objekt <uuid> --von JJJJ-MM-TT --bis JJJJ-MM-TT. Stände und Verbrauch sind Dezimal-STRINGS mit Punkt (Skala 3). Der Anfangsstand ist der letzte Stand bis zum Periodenbeginn (auch aus dem Vorjahr), der Endstand der letzte Stand bis zum Periodenende. Fehlt eine Grenze, ist das ein ehrlicher Fehlbestand: "vollstaendig": false mit den "fehlend"-Gründen (anfangsstand/endstand) — der Verbrauch wird NICHT geschätzt oder interpoliert.
zaehler zwischenstand <id>	GET	/api/zaehler/{id}/zwischenstand	ja	Zwischenstand-VORSCHLAG eines Zählers (Positional <id>) für einen Stichtag (Mieterwechsel): linear nach Kalendertagen zwischen dem letzten Stand davor und dem ersten danach, mit Begründung. Pflicht: --stichtag JJJJ-MM-TT. Der Zwischenstand ist ein VORSCHLAG und wird nicht gebucht; übernehmen heißt casa zaehler ablesen --anlass zwischenablesung --erhebungsart schaetzung. Der Abrechnungslauf bleibt ohne erklärten Schnitt fail-closed. Kein Vorschlag (mit "code"): stand-vorhanden, kein-vorher-wert, kein-nachher-wert, stand-faellt, luecke-zu-lang (mehr als 400 Tage). Stände sind Dezimal-STRINGS mit Punkt (Skala 3). Ein unbekannter oder fremder Zähler ist not_found.
zaehler pflicht	GET	/api/zaehler/pflicht	ja	Prüft, ob für ein Objekt und eine Zählerart eine Verbrauchserfassung nach HeizkostenV Pflicht ist (ab 3 Wohneinheiten, mit Ausnahme-Option am Objekt). Pflicht: --objekt <uuid> --zaehlerart <art> (waerme, wasser_warm, wasser_kalt, strom, …). Antwort "pflicht": ja \	nein \	ausnahme \	nicht-heizkostenv, dazu "hinweise". Die Pflichtprüfung ist ein Hinweis und blockiert nichts. Ein fremdes oder unbekanntes Objekt ist not_found, kein "nein".
zaehler anlegen	POST	/api/zaehler	ja	Legt einen Zähler an. Pflicht: --objekt <uuid> --art <Zählerart, z. B. wasser_kalt\	wasser_warm\	waerme\	strom>. Optional --einheit <uuid> (ohne: Allgemein-Zähler), --nummer <feste Zählernummer> ODER --praefix <Nummernkreis> (nie beides), --turnusjahr <Jahr> (für den Vorgabe-Kreis), --masseinheit <z. B. m3\	kwh>. Objekt und Standort (Einheit) sind nach der Anlage fest. Nummernkreis als Vorgabe: ohne --nummer und --praefix vergibt der Server `KW\	WW\	HZ\	ST-<Turnusjahr>-NNN` (KW kalt, WW warm, HZ Wärme, ST Strom), fortlaufend im Objekt. Die Antwort nennt die vergebene Zählernummer. Mit --idempotency-key wiederholungssicher.
zaehler sammelanlage	POST	/api/zaehler/sammelanlage	ja	Legt denselben Zählertyp für mehrere Einheiten EINES Objekts an (höchstens 500). Pflicht: --objekt <uuid> --art <Zählerart> und die Einheiten als --data '{"einheiten":[{"unitId":"<uuid>"},{"unitId":"<uuid>","meterNo":"<Nummer>"}]}'. Optional --praefix, --turnusjahr, --masseinheit. Je Einheit „angelegt" oder „vorhanden": eine Wiederholung legt nur Fehlendes an. Objekt und Standort (Einheit) sind nach der Anlage fest. Nummernkreis als Vorgabe: ohne --nummer und --praefix vergibt der Server `KW\	WW\	HZ\	ST-<Turnusjahr>-NNN` (KW kalt, WW warm, HZ Wärme, ST Strom), fortlaufend im Objekt. Mit --idempotency-key wiederholungssicher.
zaehler aendern <id>	PATCH	/api/zaehler/{id}	ja	Ändert Stammfelder EINES Zählers (Positional <id>): mindestens eines von --art, --nummer, --masseinheit. Objekt und Standort sind nach der Anlage fest (nicht änderbar); ein Zähler wird stattdessen getauscht oder stillgelegt. Ein unbekannter oder fremder Zähler ist not_found. Mit --idempotency-key wiederholungssicher.
zaehler archivieren <id>	POST	/api/zaehler/{id}/archiv	ja	Legt EINEN Zähler still (Positional <id>). Ein Zähler mit Ablesungen lässt sich erst nach dem Stand zum jüngsten Periodenende stilllegen (Konflikt OFFENE_ABLESUNG). Ein zweites Archivieren ist kein Fehler: die Antwort trägt bereitsArchiviert=true. Objekt und Standort bleiben fest. Mit --idempotency-key wiederholungssicher.
zaehler ablesen <id>	POST	/api/zaehler/{id}/ablesungen	ja	Erfasst eine Ablesung an EINEM Zähler (Positional <id>). Pflicht: --stand <Dezimalzahl mit PUNKT, höchstens 3 Nachkommastellen, z. B. 161.700; ein Komma ist ein Fehler> --am <YYYY-MM-DD oder ISO-Zeitpunkt; ein Kalendertag zählt als 00:00 UTC> --anlass turnus\	wechsel\	zwischenablesung. Optional --erhebungsart <ablesung\	schaetzung\	portal> (Standard ablesung). Plausibilitäts-Warnungen (Ausreißer, Verbrauch null) und Hinweise (Ablesefenster) stehen in der Antwort unter data.plausibilitaet; sie sind KEIN Fehler, der Stand ist dann gespeichert. Ein Stand unter dem Vorstand oder ein bereits belegter Zeitpunkt ist ein Konflikt, nichts wird gespeichert. Die Zwischenablesung am Tag des Mieterwechsels (--anlass zwischenablesung) ist die Voraussetzung der Verbrauchs-Zuordnung je Vertrag. Mit --idempotency-key wiederholungssicher.
zaehler tauschen <id>	POST	/api/zaehler/{id}/tausch	ja	Tauscht EINEN Zähler in einem Schritt (Positional <id> = der ALTE Zähler): Endstand des Altzählers, neuer Zähler, Anfangsstand, Altzähler archiviert. Die Antwort nennt die Id des neuen Zählers (data.neuZaehlerId). Pflicht: --am <YYYY-MM-DD oder ISO-Zeitpunkt> --endstand <Stand des alten Zählers, Dezimalzahl mit PUNKT, z. B. 250.000>. Optional --anfangsstand <Stand des neuen Zählers, Standard 0.000> und --neue-nummer <Zählernummer des Neugeräts>. Der Endstand darf den letzten erfassten Stand nicht unterschreiten (Konflikt). Mit --idempotency-key wiederholungssicher.
zaehler berichtigen <ablesungId>	PATCH	/api/ablesung/{ablesungId}	ja	Berichtigt den Stand EINER Ablesung (Positional <ablesungId>, die Id steht in casa zaehler ablesungen <zaehlerId>): --stand <richtiger Stand, Dezimalzahl mit PUNKT, z. B. 151.700>, optional --grund <Text>. Zeitpunkt und Anlass bleiben. Die Antwort nennt stand und vorherigerStand; die Plausibilität wird neu gerechnet (Warnungen unter data.plausibilitaet sind KEIN Fehler). Eine Ablesung, auf der eine festgeschriebene Abrechnung beruht, ist gesperrt (Konflikt ABRECHNUNG_FESTGESCHRIEBEN): Eine Korrektur läuft dann über eine neue Fassung des Abrechnungslaufs. Mit --idempotency-key wiederholungssicher.
honorar sonderleistung erfassen	POST	/api/honorar/sonderleistungen	ja	Erfasst EINE Sonderleistung des Verwalters (z. B. Mahnbescheid). Braucht --data '{"propertyId":"<uuid>","schluessel":"mahnbescheid","leistungsdatum":"YYYY-MM-DD","menge":"1"}'; optional "unitId" (Einheit des Objekts) und "notiz". Menge als Dezimal-STRING mit Punkt (je Stunde z. B. "1.25"). Preis und USt kommen aus dem Katalog des Objekts, hinterlegt als Objekt-Option: casa option set --data '{"scopeType":"objekt","scopeId":"<objekt>","key":"verwalterhonorar.sonderleistungen","value":[{"schluessel":"mahnbescheid","bezeichnung":"Mahnbescheid","preisart":"fest","preis":{"cents":"5000","currency":"EUR"},"umsatzsteuersatzProzent":"19"}]}' (preisart fest \	je_stunde \	je_einheit). Mit --idempotency-key wiederholungssicher: derselbe Schlüssel legt die Leistung nur einmal an.
honorar sonderleistung serie	POST	/api/honorar/sonderleistungen/serie	ja	Serienerfassung: EINE Leistung mit Preis je Einheit für jede Einheit, die am Leistungsdatum zum Objekt gehört — in einem Schritt (z. B. § 35a-Bescheinigung für alle Wohnungen). Braucht --data '{"propertyId":"<uuid>","schluessel":"bescheinigung_35a","leistungsdatum":"YYYY-MM-DD"}'; optional "notiz". Dieselbe Serie (Objekt, Leistung, Leistungsdatum) entsteht nur einmal — eine Wiederholung legt nichts an und meldet "bereitsErfasst":true.
honorar sonderleistung stornieren	POST	/api/honorar/sonderleistungen/storno	ja	Storniert eine erfasste Sonderleistung — sie bleibt auffindbar, zählt aber in keiner Honorarrechnung mehr. Braucht --data '{"propertyId":"<uuid>","sonderleistungId":"<uuid>","grund":"<text>"}'.
honorar sonderleistung vorlage	POST	/api/honorar/sonderleistungen/vorlage	ja	Kopiert den Vorlage-Katalog des Mandanten als eigenen Sonderleistungs-Katalog an ein Objekt (für neue Verträge). Braucht --data '{"propertyId":"<uuid>"}'. Die Vorlage selbst ist eine Mandanten-Option: casa option set --data '{"scopeType":"tenant","key":"verwalterhonorar.sonderleistungen","value":[ <Einträge> ]}'. Eine Kopie, kein Verweis — eine spätere Änderung der Vorlage ändert den Katalog des Objekts nicht.
honorar anpassen	POST	/api/honorar/anpassungen	ja	Passt die Honorarvereinbarung EINES Objekts an: neue Zeitscheibe ab --ab JJJJ-MM-01, die laufende endet am Vortag. Pflicht: --objekt <uuid> --ab JJJJ-MM-01 --grundlage beschluss\	zustimmung\	klausel --begruendung "<Text>" und die neue Vereinbarung als --data '{"neueVereinbarung":{"berechnungsart":"pauschal_je_einheit","pauschaleJeEinheitentyp":{"wohnung":{"cents":"2800","currency":"EUR"}},"satzBasispunkte":null,"mindestbetrag":null,"hoechstbetrag":null,"leerstandMindestbetrag":null,"zuschlaege":[],"umsatzsteuersatzProzent":"19"}}' (ohne gueltigAb/gueltigBis; Beträge als {"cents":"2800","currency":"EUR"}, Sätze als Integer-Strings). WEG nur mit Beschluss: --grundlage beschluss --beschluss <uuid> (der Beschluss muss angenommen oder bestandskräftig sein und zum Objekt gehören). Zustimmung des Eigentümers: --zustimmung-am JJJJ-MM-TT. Die Wirksamkeit gilt zum Monatsersten (ein Teilmonat ist nicht vereinbar); KEINE Rückwirkung auf bereits gestellte Honorarmonate. Die Erstanlage der Vereinbarung bleibt casa option set (Schlüssel verwalterhonorar.vereinbarungen). Die Antwort nennt neue und geschlossene Scheibe, den Vergleich alt/neu (Änderung in Basispunkten) und Hinweise. Mit --idempotency-key wiederholungssicher.
honorar anpassungen	GET	/api/honorar/anpassungen	ja	Geschichte der Honorar-Anpassungen EINES Objekts, neueste zuerst (Pflicht: --objekt <uuid>): Wirksamkeit, Grundlage, Beschluss, Begründung sowie alte und neue Zeitscheibe. Ohne den Akteur, der sie vorgenommen hat. Cent-Beträge und Sätze sind Integer-STRINGS.
honorar rentabilitaet	GET	/api/honorar/rentabilitaet	ja	Rentabilität EINES Objekts über einen Zeitraum ganzer Monate. Pflicht: --objekt <uuid> --von JJJJ-MM --bis JJJJ-MM (höchstens 24 Monate). Liefert Ertrag, Aufwand, Deckungsbeitrag, Marge (Basispunkte), Kapazitätsanteil und Urteil samt den geltenden Kalkulationssätzen. Ertrag ist die Honorarvorschau je Monat (Sonderleistungen mit); Aufwand ist erfasste Zeit mal Kalkulationssatz. Die Sätze kommen aus der Mandanten-Option verwalterhonorar.kalkulation (Vorgabe 60,00 € je Stunde, 136 Stunden je Monat — als Default und nicht als Wahrheit), gesetzt mit casa option set. Ohne erfasste Zeit lautet das Urteil "nicht beurteilbar", nie "wirtschaftlich". Alle Cent-Felder und Basispunkte sind Integer-STRINGS; die Marge ist null ohne Ertrag. Liest nur, bucht nichts.
zeit erfassen	POST	/api/zeit	ja	Trägt Zeit nachträglich ein. Pflicht: --objekt <uuid> --datum JJJJ-MM-TT (nicht in der Zukunft) --minuten <ganze Zahl, 1 bis 1440> --art telefonat\	aussendienst\	schriftverkehr\	versammlung\	verwaltung\	sonstiges. Optional --notiz "<Text>", --bezug-art objekt\	anliegen\	sonderleistung und --bezug-id <uuid>. Objektbezug ist Pflicht; die Zeit ist die eigene. Über 10 Stunden kommt ein Hinweis. Mit --idempotency-key wiederholungssicher.
zeit start	POST	/api/zeit/start	ja	Startet einen Timer. Pflicht: --objekt <uuid> --art telefonat\	aussendienst\	schriftverkehr\	versammlung\	verwaltung\	sonstiges. Optional --notiz, --bezug-art, --bezug-id. Objektbezug ist Pflicht; mehrere Timer dürfen gleichzeitig laufen (läuft einer an einem anderen Objekt, kommt nur ein Hinweis). Die Zeit ist die eigene. Die Antwort nennt die zeitId für casa zeit stopp <id>.
zeit stopp <id>	POST	/api/zeit/{id}/stopp	ja	Stoppt einen EIGENEN laufenden Timer (Positional <id> = zeitId aus zeit start oder zeit laufend). Die Dauer wird aus Beginn und Ende gerechnet. Ein zweites Stoppen ist ein Konflikt; der Timer eines anderen Mitarbeiters ist nicht da (not_found).
zeit korrigieren <id>	PATCH	/api/zeit/{id}	ja	Korrigiert einen EIGENEN, beendeten Eintrag (Positional <id>). Mindestens eines von --minuten <1 bis 1440>, --datum JJJJ-MM-TT, --art <Tätigkeitsart>, --notiz "<Text>". Ein laufender Timer ist nicht korrigierbar (erst stoppen), ein stornierter Eintrag nie.
zeit stornieren <id>	POST	/api/zeit/{id}/storno	ja	Storniert einen EIGENEN Eintrag (Positional <id>); er bleibt in casa zeit list auffindbar, zählt aber nirgends mehr. Pflicht: --grund "<Text>".
zeit list	GET	/api/zeit	ja	Listet die EIGENEN Zeiteinträge im Zeitraum (nach Leistungsdatum), neueste zuerst, einschließlich stornierter. Optional --objekt <uuid> --von JJJJ-MM-TT --bis JJJJ-MM-TT (beide inklusiv); ohne Zeitraum der laufende Kalendermonat. Die Zeit anderer Mitarbeiter sieht dieses Kommando nie.
zeit laufend	GET	/api/zeit/laufend	ja	Listet die laufenden Timer des Angemeldeten (mehrere sind erlaubt), ältester zuerst. Nur die eigenen.
inbox list	GET	/api/posteingang	ja	Listet die Freigabe-Inbox (wartende Buchungsvorschläge des Tenants).
ausnahmen list	GET	/api/ausnahmen	ja	Listet die Ausnahme-Inbox (offene Verarbeitungs-/Routing-Ausnahmen des Tenants).
buchung ausfuehren	POST	/api/buchung	ja	Führt einen freigegebenen Buchungsvorschlag aus. Braucht --data '{"proposalId":"<uuid>","proposalVersion":1,"entryKey":"<key>"}'. Optional "bookingDate":"YYYY-MM-DD" — rückdatiert die Ausführung; Betrag und Konto stammen aus der Freigabe, nie aus der Eingabe.
buchung eroeffnungsbestand	POST	/api/buchung/eroeffnungsbestand	ja	Migrationsnaht: baut Anfangsbestände auf (entry_type eroeffnung, beleglos, ohne Freigabe). Braucht --data '{"propertyId":"<uuid>","uebernahmestichtag":"YYYY-MM-DD","rueckstaende":[…]}'. Beträge als Integer-STRING in Cent. Idempotent je Übernahmestichtag + sourceKey.
uebernahme abrechnung	POST	/api/uebernahme/abrechnungen	ja	Übernimmt die festgeschriebene Abrechnung EINES früheren Zeitraums eines Objekts als Bestand (kein Rechnen, kein Versand, kein Step-up). Pflicht: --datei <pfad> (lokale .json-Datei, höchstens 1 MiB) mit propertyId, periodFrom, periodTo, abrechnungsdatum, uebernahmestichtag und "vertraege" (je Vertrag contractId, vorauszahlungCents, anteilCents, ergebnisCents = Anteil − Vorauszahlung, kennzeichen verbucht\	offen; bei offener Nachzahlung faelligkeitNachzahlung, bei offenem Ergebnis im Objekt "eroeffnung" {ertragKontoNr, forderungsart, geldkreis, ustSatzProzent}). Beträge als Integer-STRING in Cent. Die Datei enthält keine Personendaten außer der Vertrags-Id. Das Personenkonto des Vertrags löst der Server aus der Vertrags-Id auf (kein Personenkonto ⇒ 409); alle Datumsfelder müssen echte Kalenderdaten sein (JJJJ-MM-TT, Zeitraum von ≤ bis). Optional --pruefen: validiert und zeigt die Vorschau (Summen, geplante Eröffnungsposten, Siegel) OHNE etwas zu schreiben — dieselben 404/409-Prüfungen wie beim Übernehmen. Offene Nachzahlungen werden über die Migrationsnaht als Eröffnungs-Sollstellung mit Originalfälligkeit gebucht, offene Guthaben als Eröffnungs-Gutschrift; "verbucht" erzeugt keinen offenen Posten. Der Zeitraum muss VOR dem Übernahmestichtag enden, und für Objekt und Zeitraum darf es noch keinen Lauf geben (sonst 409 mit Klartext; ein zweiter Aufruf ohne --idempotency-key ebenfalls). Mit demselben --idempotency-key ist die Wiederholung ein Replay ohne zweite Zeile. Fremdes oder unbekanntes Objekt bzw. fremder Vertrag ⇒ 404. Eine übernommene Abrechnung kennt weder § 35a-Bescheinigung noch Einwand (409).
uebernahme abrechnungen	GET	/api/uebernahme/abrechnungen	ja	Listet die Abrechnungsläufe eines Objekts, neueste zuerst: je Lauf Zeitraum, Status, "herkunft" (uebernahme = als Bestand übernommen, sonst leer) und "uebernommen" (true/false). Braucht --propertyId <uuid>. Ein fremdes oder unbekanntes Objekt liefert eine leere Liste. Nur lesend.
abrechnung starten	POST	/api/abrechnung	ja	Startet einen Betriebskosten-Abrechnungslauf. Braucht --data '{"propertyId":"<uuid>","periodFrom":"YYYY-MM-DD","periodTo":"YYYY-MM-DD"}'. Optional "unitGroupId" (Abrechnungskreis). Blockierende Readiness-Befunde lehnen den Start ab (fail-closed).
abrechnung berechnet <id>	POST	/api/abrechnung/{id}/berechnet	ja	Setzt den Abrechnungslauf auf "berechnet" (nur bei freigabefähigem Prüfbericht). Kein --data — die Lauf-id steht im Pfad.
abrechnung ergebnis <id>	GET	/api/abrechnung/{id}	ja	Liest die Ergebniszahlen eines Abrechnungslaufs maschinenlesbar (Umlage-Zeilen + VZ-Gegenrechnung). Geld ausschließlich als Integer-STRING in Cent — nie als JSON-Zahl, nie gerundet.
abrechnung s35a-bescheinigungen <id>	GET	/api/abrechnung/{id}/s35a-bescheinigungen	ja	Erzeugt die §35a-Bescheinigungen ALLER Wohnraum-Mieter eines FESTGESCHRIEBENEN Abrechnungslaufs in einem Lauf (Serienlauf je Objekt): je Vertrag Nutzungszeitraum, Einheiten und je §35a-Kategorie (beschaeftigungsverhaeltnis/haushaltsnah/handwerker) der Arbeits-/Lohnkostenanteil — bei Bewohnerwechsel zeitanteilig, Mehrfachbuchungen summiert, dieselbe Zahl wie im §35a-Ausweis der Abrechnung. summeBescheinigungen + summeNichtBescheinigt = summeS35aKosten (cent-genau). Geld ausschließlich als Integer-STRING in Cent. Das PDF (eine Seite je Bescheinigung) liefert GET /api/abrechnung/{id}/s35a-bescheinigungen?format=pdf.
offene-posten list	GET	/api/offene-posten	ja	Liest die offenen Posten samt der drei getrennten Summen (Rückstand · Guthaben · Saldo). Filter: --propertyId --contractId --geldkreis --menge offen\	alle --richtung forderung\	guthaben\	verbindlichkeit --dueFrom --dueTo --stichtag --archiveScope --asOf. Geld ausschließlich als Integer-STRING in Cent.
bankabgleich vorlegen	POST	/api/bankabgleich/vorlegen	ja	Legt EINEN Bankumsatz als Buchungsvorschlag vor (ohne Freigabe, ohne Buchung). Braucht --data '{"bankAccountId":"<uuid>","bankTransactionId":"<uuid>","asOf":"YYYY-MM-DD"}'. Das Bankkonto (Soll) wird seit #1519 aus der Bankverbindung abgeleitet; ein trotzdem gesetztes "bankGlAccountNo" wird gegengeprüft und bei Abweichung abgewiesen. Optional "receivableGlAccountNo" und "contractId" (Vollkontierung). Die Antwort trägt die AMPEL — sie entscheidet über den Freigabeweg. Gibt der Kontenplan das Bank-Sachkonto nicht her (keine oder mehrere Zuordnungen am Objekt) oder weicht ein mitgeschicktes "bankGlAccountNo" ab, antwortet der Endpunkt mit 409 (seit #1860 kein 500 mehr): die CLI meldet dann error.code "conflict" bei Exit 1 — deterministisch, ein Retry hilft nicht, verzweige am Code. Ist die Bankverbindung nicht auflösbar (unbekannt, fremd oder archiviert), ist es "not_found" bei Exit 5. Den ausformulierten Klärungsweg trägt nur die HTTP-Antwort; die CLI druckt ihren eigenen Festtext, nicht die Server-Meldung.
bankabgleich verbuchen	POST	/api/bankabgleich/verbuchen	ja	Legt vor, gibt frei und bucht. Braucht --data mit "modus". modus="einzeln" + "kontierung" fährt die Einzel-Freigabe (gelb erlaubt, rot blockiert); modus="sammel" + "kontierungen" (1..200) fährt die Sammel-Freigabe (ALL-GREEN — ein nicht-grüner Vorschlag lässt den ganzen Aufruf scheitern, bevor etwas gebucht wird). Dazu "bankAccountId" und "asOf". Dieselben Konto-Ablehnungen wie bei "vorlegen" enden auch hier mit 409 statt mit einem Serverfehler (seit #1860): error.code "conflict" bei Exit 1, bzw. "not_found" bei Exit 5, wenn die Bankverbindung nicht auflösbar ist. Auch hier steht der ausformulierte Klärungsweg nur in der HTTP-Antwort — die CLI druckt ihren lokalen Festtext.
sollstellung starten	POST	/api/sollstellung	ja	Startet einen Sollstellungslauf. Braucht --data '{"propertyId":"<uuid>","stichtag":"YYYY-MM-DD"}'. Offene Readiness-Befunde blockieren den Start; sie lassen sich mit "uebergehen":{"begruendung":"…"} auditiert übergehen. Ergebnis sind VORSCHLÄGE — gebucht wird erst nach der Freigabe.
sollstellung freigeben	POST	/api/sollstellung/freigabe	ja	Gibt die Vorschläge eines Sollstellungslaufs in EINEM Zug frei. Braucht --data '{"proposalIds":["<uuid>",…]}'. ALL-GREEN: ein einziger nicht-grüner Vorschlag lässt den ganzen Aufruf scheitern, es wird nichts freigegeben. Keine Teil-Freigabe.
sollstellung vorschlaege <id>	GET	/api/sollstellung/{id}/vorschlaege	ja	Liest die Vorschläge EINES Sollstellungslaufs — die Quelle der "proposalIds" für sollstellung freigeben. Filter: --art neu\	storno\	ersatz, --nurOffene true\	false (nur Vorschläge ohne bindende Entscheidung). Die Reihenfolge ist die kanonische STORNO VOR ERSATZ; betragCents ist ein Integer-STRING in Cent. Unbekannter oder fremder Lauf ⇒ error.code "not_found" bei Exit 5 (kein Existenz-Orakel).
bank umsaetze <id>	GET	/api/bank/{id}/umsaetze	ja	Liest die IMPORTIERTEN Umsätze einer Bankverbindung — die Quelle der "bankTransactionId" für bankabgleich vorlegen/verbuchen. Filter: --menge alle\	offen\	gebucht (Default alle: das ist die Auskunft über den IMPORT, nicht die Arbeitsliste), --providerId (die eindeutige Bank-Referenz des Auszugs, bei camt AcctSvcrRef), --correlationId (EIN Import-Lauf), --buchungVon --buchungBis, --limit 1..200 (Default 50; "abgeschnitten" sagt, ob mehr da war). betragCents ist ein SIGNIERTER Integer-STRING in Cent (> 0 Eingang). Unbekannte oder fremde Bankverbindung ⇒ error.code "not_found" bei Exit 5. ACHTUNG: die Antwort trägt personenbezogene Daten (Verwendungszweck, Gegenkonto-IBAN, Kontoinhaber) — sie ist der Auszug, nicht eine Kennungsliste.
auswertung ust-liste	GET	/api/auswertung/ust-liste	ja	Umsatzsteuer, Vorsteuer und Zahllast EINES Objekts über einen Zeitraum, je Steuersatz und Voranmeldungs-Periode. Pflicht: --objekt <uuid> --von JJJJ-MM-TT --bis JJJJ-MM-TT. Optional: --rhythmus monat\	quartal\	jahr (Default quartal), --je-konto true (Detail je Konto und Satz; sonst ist "zeilen" null). Alle Beträge sind Integer-STRINGS in Cent, der Steuersatz ein String in ganzen Prozent. Eine Buchung ohne Steuerschlüssel auf einem steuerpflichtigen Konto erscheint unter "befunde", NICHT als steuerfreier Umsatz; ein Objekt ohne umsatzsteuerpflichtige Umsätze liefert eine leere Liste samt "hinweis".
objekt list	GET	/api/objekt	ja	Listet Objekte. --status alle\	aktiv\	archiviert (Default aktiv).
objekt get <id>	GET	/api/objekt/{id}	ja	Liest EIN Objekt samt Buchungskreis.
objekt check <id>	GET	/api/objekt/{id}/check	ja	Plausi-Gate: prüft die Objekt-Gesundheit (Ampel + Befunde als JSON). --asOf <YYYY-MM-DD> (Default heute).
objekt create	POST	/api/objekt	ja	Legt ein Objekt an (Buchungskreis entsteht automatisch). Braucht --data <json>.
objekt update <id>	PATCH	/api/objekt/{id}	ja	Ändert Objekt-Stammfelder. Braucht --data <json>.
objekt archive <id>	POST	/api/objekt/{id}/archive	ja	Archiviert Objekt + Buchungskreis (archived_at statt Löschen).
kaution liste	GET	/api/kaution	ja	Listet die Kautionen: vereinbart, erhalten, offen und die getrennte Anlage (§ 551 BGB). --propertyId <uuid> grenzt auf EIN Objekt ein, --stichtag JJJJ-MM-TT misst die Eingänge auf einen Tag (Default heute, SERVER-Uhr), --archiveScope alle\	aktiv\	archiviert steuert die Archiv-Kette. --abrechnungsstand abgerechnet\	nicht-abgerechnet\	abrechnungsreif filtert auf den Abrechnungsstand (abrechnungsreif = Vertrag beendet und nicht abgerechnet; eine Bürgschaft nie); jede Zeile trägt abrechnung (null = nicht abgerechnet). Alle Cent-Felder sind vorzeichenbehaftete Integer-STRINGS; "offenCents" ist POSITIV bei Rückstand (Win-CASA rechnet in KAUTIONSLIST.OFFEN umgekehrt). Ein dokumentarisch übernommener Bestand steht auf status "eingang-unbekannt" und trägt mahnbarerRestCents "0" — er wird durch die Umstellung NICHT gemahnt. "summen" summiert nur die EUR-Zeilen; Zeilen in anderen Währungen (etwa ein dokumentarischer CHF-Bestand) stehen je Währung getrennt in "summenFremdwaehrung". "anlagenOhneSachkonto" nennt Kautionskonten ohne zugeordnetes Bank-Sachkonto: deren Eingänge konnten nicht mitgezählt werden. ACHTUNG: die Antwort trägt personenbezogene Daten (Mietpartei, IBAN der Anlage).
kaution abrechnung-stand	GET	/api/kaution/abrechnung	ja	Liest den gespeicherten Abrechnungsstand EINES Vertrags: --contractId <uuid>. Die Antwort trägt die nicht stornierte Kautionsabrechnung mit Auszahlung, Restforderung und Rückbehalt-Status "keiner" \	"gehalten" \	"freigegeben". Fremder oder unbekannter Vertrag ⇒ 404; Vertrag ohne geltende Abrechnung ⇒ 404 mit Code KAUTION_KEINE_ABRECHNUNG. Cent-Felder sind Integer-STRINGS. ACHTUNG: "rueckbehaltBegruendung" ist Freitext (personenbezogen).
kaution zinsstand	GET	/api/kaution/zinsen/stand	ja	Zeigt je Kautions-Anlagekonto (Kontoart kautionskonto) den Zinsstand: "von"/"bis" des zuletzt gebuchten Zinszeitraums ("bis": null, wenn noch kein Zinslauf gebucht ist), "anzahlBarkautionen" auf dem Konto und "unverteilteUmsaetze" — Haben-Umsätze, die noch kein Buchungsanspruch (Eingang) belegt, mit Betrag (Integer-STRING in Cent) und Wertstellung. Ob ein Umsatz ein Zins ist, entscheidet der Befehl nicht; "naechstesOffenesJahr" ist die Eingabe --jahr des Zinslauf-Vorschlags (kaution zinsen vorschlag). Nur lesend; zeigt nur Konten der Objekte, für die der Aufrufer zuständig ist.
kaution fristen	GET	/api/kaution/rueckbehalt-fristen	ja	Zeigt je gehaltenem Rückbehalt (Kautionsabrechnung im Status "gehalten" oder "teilfreigegeben", nicht storniert) das Fristende und die Überfälligkeit: Vertrag, "abrechnungsdatum", "rueckbehaltCents" und "restCents" (Integer-STRINGS in Cent), "fristEnde" (beim Buchen gespeicherter Termin (Wiedervorlage am): Abrechnungsdatum + Frist des Mandanten zum Buchungszeitpunkt, siehe "kaution einstellung"; eine spätere Änderung der Frist wirkt nur auf neue Abrechnungen), "ueberfaellig" und "tageUeberfaellig". Optional --stichtag <JJJJ-MM-TT> (Vorgabe: heute, Server-Uhr) und --nurUeberfaellig <true\	false>. Nur lesend — keine automatische Aktion, keine Mail; zeigt nur Rückbehalte der Objekte, für die der Aufrufer zuständig ist.
instandhaltung list	GET	/api/instandhaltung	ja	Listet die Instandhaltungs-Vorgänge: "vorgangId", "nummer", "titel", "typSchluessel", "dringlichkeit" (sofort \	kurzfristig \	langfristig), "status" (gemeldet \	in_klaerung \	angebote_offen \	zur_freigabe \	freigegeben \	beauftragt \	ausgefuehrt \	abgerechnet \	abgeschlossen \	storniert) mit "statusSeit", "objekt", "einheit", "auftragswert" (Integer-String in Cent, null ohne lebenden Auftrag), "auftragsnummer" und "offeneBefunde". Optional --propertyId <uuid>, --status <wert[,wert]>, --dringlichkeit <wert[,wert]>, --typ <schluessel>, --nurOffen <true\	false> (ohne abgeschlossen und storniert), --limit (Vorgabe 50, höchstens 200) und --offset. Ohne Vorgänge ist die Liste leer. Nur lesend; zeigt nur Vorgänge der Objekte, für die der Aufrufer zuständig ist. Geld ist ein Integer-String in Cent.
instandhaltung show <id>	GET	/api/instandhaltung/{id}	ja	Zeigt EINEN Instandhaltungs-Vorgang: "status" mit "verlauf", "angebote", "auftraege", den Freigabestand des lebenden Auftrags ("freigabe": erforderliche, offene und abgelehnte Stufen), "rechnungen" mit Zahlungsstand ("zahlungsstand.stand": nicht-gebucht \	offen \	ausgeglichen, dazu nicht-ermittelbar, wenn der Buchungssatz keine lesbare Verbindlichkeit ist), die aktuellen "befunde" (Code, Schwere, Text) und die "naechsteSchritte". Optional --stichtag <JJJJ-MM-TT> (Vorgabe: Berliner Tag der Server-Uhr). Ein fremder, unbekannter oder nicht sichtbarer Vorgang ergibt "not_found". Nur lesend. Geld ist ein Integer-String in Cent.
instandhaltung katalog	GET	/api/instandhaltung/katalog	ja	Zeigt den Vorgangstypen-Katalog des Mandanten: "schluessel", "bezeichnung", "ohneAngebotErlaubt", "aktiv" und "vorgabe" (Typ aus der Vorgabe des Systems). Standardmäßig nur aktive Typen; --auchInaktive true zeigt alle. Nur lesend.
instandhaltung einstellung	GET	/api/instandhaltung/einstellung	ja	Zeigt die Instandhaltung-Einstellung des Mandanten: "zweitfreigabeAbCents" (Auftragswert, ab dem eine Zweitfreigabe nötig ist; null ⇒ nie), "vergleichsangeboteAbCents" (Integer-Strings in Cent), "mindestangebote" und "herkunft" (vorgabe \	mandant). Ohne gespeicherte Einstellung gilt die Vorgabe. Nur lesend.
instandhaltung aufgaben	GET	/api/instandhaltung/aufgaben	ja	Zeigt die offene Instandhaltung-Arbeit als Aufgaben: "aufgabeArt" (sofort-unbearbeitet \	angebot-ausstehend \	freigabe-wartet \	rechnung-fehlt), "ampel", "titel", "objektId", "frist" und "vorgangId". Optional --stichtag <JJJJ-MM-TT> (Vorgabe: Berliner Tag der Server-Uhr) und --propertyId <uuid>. Nur lesend; zeigt nur Vorgänge der Objekte, für die der Aufrufer zuständig ist.
instandhaltung einstellung setzen	PUT	/api/instandhaltung/einstellung	ja	Setzt die Instandhaltung-Einstellung des Mandanten. Braucht --data '{"zweitfreigabeAbCents":"500000","vergleichsangeboteAbCents":"100000","mindestangebote":3}' — Schwellen als Ziffern-String in Cent (zweitfreigabeAbCents null = nie), mindestangebote eine ganze Zahl. Nur ein Mensch mit Recht (sonst 403). Antwort: gesetzte Werte, "vorher" und "geaendert". Wiederholungssicher mit --idempotency-key.
instandhaltung katalog setzen	PUT	/api/instandhaltung/katalog	ja	Legt einen Vorgangstyp im Katalog des Mandanten an oder ändert ihn. Braucht --data '{"schluessel":"heizung","bezeichnung":"Heizung","ohneAngebotErlaubt":false,"aktiv":true}'. Nur ein Mensch mit Recht (sonst 403). Wiederholungssicher mit --idempotency-key.
instandhaltung melden	POST	/api/instandhaltung	ja	Erfasst eine Meldung. Pflichtfelder in --data: propertyId (uuid), typSchluessel (aktiver Typ, siehe casa instandhaltung katalog), titel (1 bis 140 Zeichen), beschreibung (10 bis 5000 Zeichen), dringlichkeit (sofort \	kurzfristig \	langfristig). Optional unitId, melderPersonId, beginnAm (JJJJ-MM-TT), haeufigkeit, baulichVeraendernd. Beispiel: --data '{"propertyId":"<uuid>","typSchluessel":"schaden","titel":"Wasserschaden Bad","beschreibung":"Wasser tritt an der Decke aus.","dringlichkeit":"sofort"}'. Antwort: vorgangId, nummer, status gemeldet, naechsteSchritte, befunde. Ohne --data wird nichts gesendet. Wiederholungssicher mit --idempotency-key.
instandhaltung qualifizieren <id>	POST	/api/instandhaltung/{id}/qualifizieren	ja	Qualifiziert den Vorgang <id>: Typ, Dringlichkeit, baulich verändernd, Beginn und Häufigkeit oder ausdrücklich "beginnUnbekannt". Beispiel: --data '{"beginnAm":"2026-11-01","haeufigkeit":"täglich"}' oder --data '{"beginnUnbekannt":true}'. Aus gemeldet wird in_klaerung; ab angebote_offen sind die Angaben eingefroren (Konflikt). Antwort: status, naechsteSchritte, befunde, uebergang.
instandhaltung dienstleister <id>	POST	/api/instandhaltung/{id}/dienstleister	ja	Weist dem Vorgang <id> einen Dienstleister zu (es entsteht ein Angebot im Status angefragt). Braucht --data '{"dienstleisterPersonId":"<uuid>"}'; die Person muss am Tag die Rolle dienstleister tragen (sonst 400). Derselbe Dienstleister zweimal ist ein Konflikt.
instandhaltung angebot <id>	POST	/api/instandhaltung/{id}/angebot	ja	Erfasst das Angebot eines zugeordneten Dienstleisters für den Vorgang <id>. Beispiel: --data '{"dienstleisterPersonId":"<uuid>","betrag":{"cents":"120000","currency":"EUR"},"gueltigBis":"2026-12-31"}'. Geld ist ein Objekt {cents, currency} (Cent als Ziffern-String, currency EUR). Optional gueltigBis, realisierungAb (JJJJ-MM-TT), dokumentId.
instandhaltung angebot waehlen <id>	POST	/api/instandhaltung/{id}/angebot/waehlen	ja	Wählt ein vorliegendes Angebot des Vorgangs <id>. Braucht --data '{"angebotId":"<uuid>"}'. Antwort: das Angebot (Geld als {cents, currency}), anzahlAngebote und ein möglicher Befund (z. B. zu wenige Vergleichsangebote).
instandhaltung angebot verwerfen <id>	POST	/api/instandhaltung/{id}/angebot/verwerfen	ja	Verwirft ein Angebot des Vorgangs <id> mit Grund. Braucht --data '{"angebotId":"<uuid>","grund":"zu teuer"}' (grund 1 bis 200 Zeichen).
instandhaltung freigabe beantragen <id>	POST	/api/instandhaltung/{id}/freigabe	ja	Beantragt die Kostenfreigabe des Vorgangs <id> (Auftrag im Status zur_freigabe). Beispiel: --data '{"angebotId":"<uuid>"}'; optional kostenobergrenze, dienstleisterPersonId, costCategoryId. Ohne Angebot nur bei Typen, die das erlauben. Geld ist ein Objekt {cents, currency} (Cent als Ziffern-String, currency EUR). Antwort: auftragId, version, betrag, stufen (verwalter \	zweit), zweitstufeNichtWirksam, befunde.
instandhaltung freigabe entscheiden <id>	POST	/api/instandhaltung/{id}/freigabe/entscheid	ja	Entscheidet eine Stufe der Kostenfreigabe des Vorgangs <id>. Beispiel: --data '{"stufe":"verwalter","decision":"approved"}'; Ablehnung: --data '{"stufe":"verwalter","decision":"rejected","rejectReason":{"code":"zu-teuer"}}' (code: zu-teuer \	angebot-unklar \	beschluss-fehlt \	sonstiges, optional note). Eine zweite Stufe ("zweit") ist nur bei aktivem Vier-Augen-Schalter und erreichter Schwelle nötig. Wer den Antrag gestellt hat, darf bei aktivem Vier-Augen nicht selbst freigeben (403). Antwort: entschieden, auftragStatus, vorgangStatus, offeneStufen, ohneVierAugen.
fremdvertrag list	GET	/api/fremdvertrag	ja	Listet die Verträge mit Dritten (Versicherung, Wartung, Dienstleistung, Versorgung): "id", "art", "bezeichnung", "partner", "beginn", "konditionen" zum Stichtag (Beitrag, Jahresbeitrag und Selbstbehalt als Integer-String in Cent), "fristen" (spaetesterZugang, aufgabeAb), "beendet" und "anzahlSchadenfaelle". Optional --propertyId <uuid>, --art <versicherung\	wartung\	dienstleistung\	versorgung>, --status <aktiv\	beendet\	alle> (Vorgabe aktiv), --limit (Vorgabe 50, höchstens 200) und --offset. Ohne Verträge ist die Liste leer. Nur lesend; zeigt nur Verträge der Objekte, für die der Aufrufer zuständig ist. Geld ist ein Integer-String in Cent.
fremdvertrag show <id>	GET	/api/fremdvertrag/{id}	ja	Zeigt EINEN Vertrag mit Dritten: "vertrag" (Art, Bezeichnung, Partner, Objekt, Beginn), "konditionen" zum Stichtag und "historie", "ereignisse", den Fristenstand ("fristen": spaetesterZugang, aufgabeAb, verpasstesEnde, befunde), den Dauerzahlungs-Abgleich ("dauerzahlungAbgleich" mit Befund beitrag-weicht-von-dauerzahlung-ab) und die "schadenfaelle". Optional --stichtag <JJJJ-MM-TT> (Vorgabe: Berliner Tag der Server-Uhr). Ein fremder, unbekannter oder nicht sichtbarer Vertrag ergibt "not_found". Nur lesend. Geld ist ein Integer-String in Cent.
fremdvertrag fristen	GET	/api/fremdvertrag/fristen	ja	Zeigt den Fristenwächter der Verträge mit Dritten: je Zeile "kategorie" (kuendigungsfrist \	frist-verpasst \	ohne-laufzeit), "spaetesterZugang" (letzter Tag, an dem die Kündigung zugehen muss), "aufgabeAb", "tageBisFrist" (negativ, wenn verstrichen), "ampel", "vertragsende", "refId" (der Vertrag) und "offen". Optional --stichtag <JJJJ-MM-TT> (Vorgabe: Berliner Tag der Server-Uhr), --propertyId <uuid>, --art <versicherung\	wartung\	dienstleistung\	versorgung>, --nurOffen <true\	false> (Vorgabe true: nur Handlungsbedarf) und --mitUeberwachungsluecken <true\	false> (Verträge ohne Laufzeitende, Kategorie ohne-laufzeit). Ohne Fristen ist die Liste leer. Nur lesend, keine Aktion, keine Mail; zeigt nur Verträge der Objekte, für die der Aufrufer zuständig ist.
fremdvertrag einstellung	GET	/api/fremdvertrag/einstellung	ja	Zeigt die Einstellung der Verträge mit Dritten: "vorlaufTage" (Aufgabe ab Zugangstermin minus Vorlauf), "verlaengerungStillschweigendVorgabe", "verlaengerungMonateVorgabe", "schadenMeldefristTage", "schadenhonorarProzentBp" (Basispunkte), "schadenhonorarProzentText", "schadenhonorarAktiv" und "herkunft" (vorgabe \	mandant). Ohne gespeicherte Einstellung gilt die Vorgabe. Nur lesend.
schadenfall list	GET	/api/schadenfall	ja	Listet die Schadenfälle: "id", "nummer", "status" (erfasst \	gemeldet \	deckung_zugesagt \	deckung_abgelehnt \	reguliert \	abgeschlossen), "schadensdatum", "schadenart", "objekt", "schadenssumme" (Integer-String in Cent, null, wenn unbekannt) und "anzahlBefunde". Optional --propertyId <uuid>, --status <wert[,wert]>, --versicherungsvertragId <uuid>, --instandhaltungVorgangId <uuid>, --nurOffen <true\	false> (ohne abgeschlossen), --limit (Vorgabe 50, höchstens 200) und --offset. Ohne Schadenfälle ist die Liste leer. Nur lesend; zeigt nur Fälle der Objekte, für die der Aufrufer zuständig ist. Geld ist ein Integer-String in Cent.
schadenfall show <id>	GET	/api/schadenfall/{id}	ja	Zeigt EINEN Schadenfall: "schadenfall" (Status, Schadensdatum, Schadenart, Selbstbehalt, Schadenssumme), "versicherungsvertrag", "instandhaltungVorgang", die "befunde" (meldefrist-verstrichen \	schaden-ausserhalb-laufzeit \	versicherung-fehlt \	erstattung-weicht-ab), die "bilanz" (Schadenssumme, Selbstbehalt, erwartete Erstattung, erstattet, Differenz), die "erstattungen" mit Buchungsstand (gebucht \	vorgeschlagen) und den "honorar"-Vorschlag; der Honorar-Vorschlag wird nicht automatisch abgerechnet. Optional --stichtag <JJJJ-MM-TT> (Vorgabe: Berliner Tag der Server-Uhr). Ein fremder, unbekannter oder nicht sichtbarer Schadenfall ergibt "not_found". Nur lesend. Geld ist ein Integer-String in Cent.
mieterhoehung staffelliste	GET	/api/mieterhoehung/staffelliste	ja	Zeigt die Staffelmieterhöhungsliste: je Vertrag mit mindestens einem Kaltmieten-Wechsel die zum Stichtag geltende ("aktuell") und die unmittelbar vorherige Kaltmiete ("vorher") mit Gültigkeitsbeginn ("gueltigAb"), die Differenz ("differenzCents", Integer-STRING in Cent), die nächste künftige Stufe ("naechste") und die Herkunft des Wechsels ("herkunft": "anlage" = im Anlage-Kommando des Vertrags entstanden, sonst "konditionswechsel"). Optional --stichtag <JJJJ-MM-TT> (Vorgabe: heute, Server-Uhr), --von/--bis <JJJJ-MM-TT> (nur Verträge, deren aktuelle Stufe in diesem Zeitraum gültig wurde) und --objekt <uuid>. Nur lesend; zeigt nur Verträge der Objekte, für die der Aufrufer zuständig ist.
mieterhoehung faellig	GET	/api/mieterhoehung/faellig	ja	Zeigt je laufendem Wohnraumvertrag, wer für eine Mieterhöhung fällig ist: "paragraph558" (frühester Termin aus der Jahressperrfrist = letzte Erhöhung + 12 Monate, "status" faellig \	noch-nicht-faellig \	gesperrt; gesperrt mit "grund" bei Index- oder Staffelvereinbarung), bei Indexmiete "paragraph557b" (frühester Anpassungstermin, "juengsterVpiMonat" und die neue Miete "neueKaltmieteCents" als Vorschau, Integer-STRING in Cent; "vpi-fehlt" bzw. "basisjahr-abweichend" statt eines geschätzten oder umgerechneten Werts) und "offenerVorgang" mit dem Ende der Zustimmungsfrist eines versendeten Vorgangs. Optional --stichtag <JJJJ-MM-TT> (Vorgabe: heute, Server-Uhr). Nur lesend — kein Vorgang, keine Mail; Gewerbeverträge erscheinen nicht; zeigt nur Verträge der Objekte, für die der Aufrufer zuständig ist.
mahnlauf list	GET	/api/mahnlauf	ja	Zeigt die offenen Mahnlauf-Vorgänge (fällig oder in Arbeit) der Objekte, für die der Aufrufer zuständig ist, den Vorgang, den das Register öffnet ("gewaehlt"; --lauf <vorgangId> ist der Deep-Link), die früheren (ausgeführten) Vorgänge und — ohne offenen Vorgang — "zuMahnendeDebitoren". Ein Vorgang gehört dem, der ihn bearbeitet ("inArbeitBei", "fremdInArbeit"). Nur lesend — nichts davon mahnt.
mahnlauf show <id>	GET	/api/mahnlauf/{id}	ja	Zeigt EINEN Mahnlauf-Vorgang: Kopf (Stichtag, Status, Schritt, Summen, wer ihn bearbeitet), Umfang (Objekte und Einheiten der Zuständigkeit), die Positionen mit "schluessel" (für ausschliessen/zurueckholen) und Beträgen als Integer-STRINGS in Cent, bei einem ausgeführten Vorgang das Ergebnis. Fremder oder unbekannter Vorgang ⇒ dieselbe 404. Nur lesend — nichts davon mahnt.
mahnlauf starten	POST	/api/mahnlauf	ja	Startet einen Mahnlauf-Vorgang oder öffnet den eigenen, schon vorbereiteten: --stichtag <JJJJ-MM-TT> (Pflicht), --automatisch (Schalter, Vorgabe aus). Ein zweiter Aufruf desselben Nutzers zum selben Stichtag öffnet denselben Vorgang ("neu": false) und legt keinen zweiten an. Ein Vorgang gehört dem, der ihn bearbeitet: ist er bei jemand anderem in Arbeit, ist er nur anzusehen — nichts geschrieben. Ein ausgeführter Vorgang ist nicht mehr änderbar. Ein Objekt, das ein anderer offener Vorgang hält, ist im Umfang nicht wählbar. Ausführen, Freigabe und Versand folgen in einem eigenen Schritt — nichts davon mahnt schon.
mahnlauf stichtag <id>	PATCH	/api/mahnlauf/{id}	ja	Setzt den Stichtag eines Vorgangs: <vorgangId> --stichtag <JJJJ-MM-TT>. Ein Vorgang gehört dem, der ihn bearbeitet: ist er bei jemand anderem in Arbeit, ist er nur anzusehen — nichts geschrieben. Ein ausgeführter Vorgang ist nicht mehr änderbar. Ein Objekt, das ein anderer offener Vorgang hält, ist im Umfang nicht wählbar. Nichts davon mahnt schon.
mahnlauf umfang <id>	PATCH	/api/mahnlauf/{id}	ja	Setzt den Umfang eines Vorgangs: <vorgangId> --data '{"objektIds":["<uuid>"],"abgewaehlteEinheitIds":[]}' — die Objekte im Umfang und die abgewählten Einheiten (beide Listen Pflicht, ggf. leer). Gewählt werden können nur Objekte, für die der Aufrufer zuständig ist. Ein Vorgang gehört dem, der ihn bearbeitet: ist er bei jemand anderem in Arbeit, ist er nur anzusehen — nichts geschrieben. Ein ausgeführter Vorgang ist nicht mehr änderbar. Ein Objekt, das ein anderer offener Vorgang hält, ist im Umfang nicht wählbar. Nichts davon mahnt schon.
mahnlauf schritt <id>	PATCH	/api/mahnlauf/{id}	ja	Merkt den Schritt (0 bis 3) eines Vorgangs: <vorgangId> --schritt <0..3>. Ein Schritt über 0 nimmt den Vorgang in Arbeit — ab da gehört er dem Aufrufer. Ein Vorgang gehört dem, der ihn bearbeitet: ist er bei jemand anderem in Arbeit, ist er nur anzusehen — nichts geschrieben. Ein ausgeführter Vorgang ist nicht mehr änderbar. Ein Objekt, das ein anderer offener Vorgang hält, ist im Umfang nicht wählbar. Nichts davon mahnt schon.
mahnlauf ausschliessen <id>	POST	/api/mahnlauf/{id}/ausschluss	ja	Nimmt eine Position aus dem Mahnlauf: <vorgangId> --position <schluessel> (aus "mahnlauf show") --grund "<Text>" (Pflicht, höchstens 200 Zeichen). Ohne Grund wird nichts gesendet. Erneutes Ausschließen lässt eine Zeile stehen (der jüngere Grund gilt); der Grund steht nicht in der Antwort. Ein Vorgang gehört dem, der ihn bearbeitet: ist er bei jemand anderem in Arbeit, ist er nur anzusehen — nichts geschrieben. Ein ausgeführter Vorgang ist nicht mehr änderbar. Ein Objekt, das ein anderer offener Vorgang hält, ist im Umfang nicht wählbar. Nichts davon mahnt schon.
mahnlauf zurueckholen <id>	POST	/api/mahnlauf/{id}/ausschluss/aufheben	ja	Holt eine ausgeschlossene Position in den Mahnlauf zurück: <vorgangId> --position <schluessel>. Gab es keinen Ausschluss, ist das ein Erfolg ohne Wirkung ("zurueckgeholt": false). Ein Vorgang gehört dem, der ihn bearbeitet: ist er bei jemand anderem in Arbeit, ist er nur anzusehen — nichts geschrieben. Ein ausgeführter Vorgang ist nicht mehr änderbar. Ein Objekt, das ein anderer offener Vorgang hält, ist im Umfang nicht wählbar. Nichts davon mahnt schon.
mahnlauf ausfuehren <id>	POST	/api/mahnlauf/{id}/ausfuehren	ja	Führt einen vorbereiteten Mahnlauf-Vorgang aus: <vorgangId>. Erzeugt je Schreiben einen Eintrag und gibt die unauffälligen Schreiben frei; markierte Schreiben sind danach einzeln freizugeben (mahnlauf freigeben), der Versand ist ein eigener Schritt (mahnlauf versand). Ein zweiter Aufruf liefert das Erst-Ergebnis ("erstAusfuehrung": false). Wirkt nach außen: verlangt eine frische Anmeldung (casa auth login --frisch, sonst 403 step_up_required und nichts geschrieben) und das Ausführungsrecht; ein Agent darf nicht (403, nichts geschrieben). Eine Selbstfreigabe wird je nach Mandantenregel abgelehnt (403).
mahnlauf versand <id>	POST	/api/mahnlauf/{id}/versand	ja	Versendet die Schreiben eines AUSGEFÜHRTEN Vorgangs: <vorgangId> --versandweg mail\	druck (Pflicht, sonst Bedienfehler ohne Netzaufruf); optional --data '{"mahnschreibenIds":["<uuid>"]}' setzt den Versand nur für diese Schreiben fort. Antwort: Zähler (versandt, fehlgeschlagen, uebersprungen) und je Schreiben der Ausgang. Der Versand hat eine eigene frische Anmeldung (ein zweiter Versand desselben Laufs oder Schreibens ist ausgeschlossen: 409, die Anmeldung wird nicht verbraucht), und er geht nur, wenn der Vorgang ausgeführt ist und mindestens ein Schreiben "download_bereit" ist. Wirkt nach außen: verlangt eine frische Anmeldung (casa auth login --frisch, sonst 403 step_up_required und nichts geschrieben) und das Ausführungsrecht; ein Agent darf nicht (403, nichts geschrieben). Eine Selbstfreigabe wird je nach Mandantenregel abgelehnt (403).
mahnlauf freigeben <id> <schreibenId>	POST	/api/mahnlauf/{id}/schreiben/{schreibenId}/freigabe	ja	Entscheidet über EIN Schreiben einzeln: <vorgangId> <schreibenId> --entscheidung freigeben\	zurueckweisen (Pflicht). Beim Zurückweisen ist --grund <Code> Pflicht (falscher-betrag, falscher-kreditor, falsche-kontierung, kein-beleg, doppelt, nicht-plausibel, sonstiges), optional --notiz "<Text>" (höchstens 500 Zeichen); bei freigeben ist kein Grund erlaubt. Nach freigeben folgt der Versand genau dieses Schreibens (Versandweg mail, eigene frische Anmeldung); eine rote Ampel ist nicht freigebbar. Wirkt nach außen: verlangt eine frische Anmeldung (casa auth login --frisch, sonst 403 step_up_required und nichts geschrieben) und das Ausführungsrecht; ein Agent darf nicht (403, nichts geschrieben). Eine Selbstfreigabe wird je nach Mandantenregel abgelehnt (403).
mahnlauf zustellung <id> <schreibenId>	POST	/api/mahnlauf/{id}/schreiben/{schreibenId}/zustellung	ja	Dokumentiert die von Hand erfolgte Zustellung EINES Schreibens: <vorgangId> <schreibenId> --am <JJJJ-MM-TT> --kanal brief\	einschreiben\	persoenliche_uebergabe --bestaetigt (Schalter: "ich bestätige, dass die Zustellung tatsächlich erfolgt ist"; ohne ihn 400). Genau ein Nachweis je Schreiben: eine zweite Dokumentation ⇒ 409 (bereits-dokumentiert). Wirkt nach außen: verlangt eine frische Anmeldung (casa auth login --frisch, sonst 403 step_up_required und nichts geschrieben) und das Ausführungsrecht; ein Agent darf nicht (403, nichts geschrieben). Eine Selbstfreigabe wird je nach Mandantenregel abgelehnt (403).
mahnlauf erneut <id> <schreibenId>	POST	/api/mahnlauf/{id}/schreiben/{schreibenId}/erneut	ja	Sendet EIN fehlgeschlagenes Schreiben erneut: <vorgangId> <schreibenId>. Nur für den Status "fehlgeschlagen" (sonst 409); ein zweiter Versand desselben Schreibens ist ausgeschlossen. Schlägt der Weg wieder fehl, steht "ausgang": "fehlgeschlagen" in der Antwort (Exit 0). Wirkt nach außen: verlangt eine frische Anmeldung (casa auth login --frisch, sonst 403 step_up_required und nichts geschrieben) und das Ausführungsrecht; ein Agent darf nicht (403, nichts geschrieben). Eine Selbstfreigabe wird je nach Mandantenregel abgelehnt (403).
mahnlauf schreiben <id> <schreibenId>	GET	/api/mahnlauf/{id}/schreiben/{schreibenId}/datei	ja	Lädt die Datei EINES Mahnschreibens nach --out <pfad> (Pflicht, sonst Bedienfehler ohne Netzaufruf): <vorgangId> <schreibenId>; byte-genau, die CLI prüft die sha256; ein vorhandenes Ziel nur mit --ueberschreiben. Im Umschlag steht "geschriebenNach" statt der Base64-Bytes. Der Download wird vermerkt. Keine Außenwirkung, keine frische Anmeldung nötig. Schreiben eines fremden Vorgangs ⇒ 404.
inkasso list	GET	/api/inkasso	ja	Listet die Inkasso-Übergaben des Mandanten, neueste zuerst: --objekt <objektId> und --status entwurf\	uebergeben\	zurueckgenommen\	abgeschlossen schränken ein. Cent-Felder sind Integer-STRINGS; Empfänger, Begründung, Grund und Notiz sind Freitext. Nur lesend. Die Übergabe ist ein Datensatz: sie sendet nichts an Dritte und erzeugt kein Partnerformat.
inkasso show <id>	GET	/api/inkasso/{id}	ja	Zeigt EINE Inkasso-Übergabe: <id>. Kopf (Weg, Status, Stichtag, Gesamtforderung), die eingefrorene Forderungsaufstellung (je Posten Hauptforderung, Mahnstufe, Mahngebühren, Verzugszinsen bis zum Stichtag, alle Beträge als Integer-STRINGS in Cent, dazu Tageszins und Hinweise) und die Postenliste. Fremde oder unbekannte Übergabe ⇒ dieselbe 404. Nur lesend; die Übergabe sendet nichts an Dritte.
inkasso anlegen	POST	/api/inkasso	ja	Legt eine Inkasso-Übergabe als ENTWURF an: --objekt <objektId> --schuldner <personId> [--vertrag <vertragId>] --weg inkasso\	gerichtliches-mahnverfahren\	klage [--empfaenger "<Text>"] --stichtag <JJJJ-MM-TT> und die Posten als --data '{"offenePostenIds":["<uuid>",…]}'. Die Forderungsaufstellung (Hauptforderung, Mahngebühren, Verzugszinsen bis zum Stichtag) wird gebildet, gehasht und eingefroren. Voraussetzung ist Mahnstufe 3 oder anwalt; darunter nur mit --begruendung-mahnstufe "<Text>". Derselbe Posten kann nicht in zwei aktiven Übergaben stehen (409). Die Übergabe ist ein Datensatz: sie sendet nichts an Dritte und erzeugt kein Partnerformat. Mit "inkasso uebergeben" wird sie übergeben.
inkasso uebergeben <id>	POST	/api/inkasso/{id}/uebergabe	ja	Übergibt den Entwurf: <id> --am <JJJJ-MM-TT> (Pflicht). Setzt den Mahnstatus jedes Postens auf "Beim Rechtsanwalt" (anwalt), in derselben Transaktion. Die Übergabe ist ein Datensatz: sie sendet nichts an Dritte und erzeugt kein Partnerformat. Eine zweite Übergabe ⇒ 409.
inkasso zuruecknehmen <id>	POST	/api/inkasso/{id}/zuruecknahme	ja	Nimmt die Übergabe zurück: <id> --grund "<Text>" (Pflicht, höchstens 500 Zeichen; ohne Grund wird nichts gesendet). Die Posten werden frei; der Mahnstatus "Beim Rechtsanwalt" wird NICHT zurückgestuft. Die Übergabe ist ein Datensatz: sie sendet nichts an Dritte.
inkasso abschliessen <id>	POST	/api/inkasso/{id}/abschluss	ja	Schließt die übergebene Übergabe ab: <id> --art bezahlt\	vergleich\	uneinbringlich\	sonstiges (Pflicht) [--notiz "<Text>"]. Die Posten werden frei. Die Übergabe ist ein Datensatz: sie sendet nichts an Dritte.
inkasso aufstellung <id>	GET	/api/inkasso/{id}/forderungsaufstellung	ja	Schreibt die Forderungsaufstellung einer Übergabe als CSV-Datei nach --out <pfad> (Pflicht, sonst Bedienfehler ohne Netzaufruf): <id>; byte-genau, die CLI prüft die sha256; ein vorhandenes Ziel nur mit --ueberschreiben. Die CSV ist Semikolon-getrennt, UTF-8 mit BOM, Dezimalkomma; zweimal geladen ist sie byte-gleich. Im Umschlag steht "geschriebenNach" statt der Base64-Bytes, dazu "aufstellungHash". Reiner Lesezugriff: nichts wird geschrieben oder gesendet — die Übergabe ist ein Datensatz und erzeugt kein Partnerformat.
kaution abrede <id>	POST	/api/vertrag/{id}/kaution	ja	Hält die Kautionsabrede eines Vertrags fest: Betrag + Währung, Anlageform ("barkaution" \	"buergschaft" \	"verpfaendung"), Raten nach § 551 Abs. 2 BGB (1…3, nur und Pflicht bei Barkaution) und die getrennte Anlage. Braucht --data '{"depositCents":"240000","depositCurrency":"EUR","kautionAnlageform":"barkaution","kautionRaten":3,"kautionAnlagekontoId":"<uuid>"}' — depositCents/depositCurrency nur gemeinsam und Pflicht, wenn der Vertrag noch keine Kaution dokumentiert (sonst gilt der dokumentierte Betrag); kautionAnlagekontoId ist eine Bankverbindung der Kontoart kautionskonto am Objekt und Voraussetzung für "kaution eingang". Erst danach stellt "kaution sollstellen" Raten; ohne Abrede bleibt eine übernommene Kaution dokumentarisch ("vereinbart, Eingang unbekannt") und wird nie gemahnt. Mehr als 3 Raten ⇒ 400; sind schon Raten oder Eingänge gebucht ⇒ 409.
mieterhoehung anlegen <id>	POST	/api/vertrag/{id}/mieterhoehung	ja	Legt ein Mieterhöhungsverlangen nach § 558 BGB für einen Vertrag an: Vorgang im Zustand "entwurf" plus dokumentiertes Schreiben, der Vorgang erscheint in der Freigabe — es entsteht KEINE Zeitscheibe (umgestellt wird erst nach "mieterhoehung entscheiden" ... approved über die Konditionen). Braucht <vertragId> und --data '{"wirksamAb":"2027-01-01","zugangAm":"2026-10-01","neueKaltmieteCents":"90000","currency":"EUR","vergleichsmieteCents":"95000","gebiet":"regel","laufendeVereinbarung":"keine","payments":[],"begruendung":{"weg":"mietdatenbank","bezeichnung":"Mietdatenbank Beispielstadt","standJahr":2025},"verwaltung":{"art":"eigenverwaltung"}}' — Cent-Felder sind Integer-STRINGS; "payments" ist Pflicht (auch leer); "begruendung.weg": qualifizierter-mietspiegel \	einfacher-mietspiegel \	mietdatenbank \	vergleichswohnungen \	sachverstaendigengutachten. Antwort: mieterhoehungId, schreibenId, zustimmungsfristBis. Kappungsgrenze/Jahressperrfrist verletzt ⇒ 409 MIETERHOEHUNG_UNZULAESSIG; schon ein Verlangen zu dem Tag ⇒ 409 MIETERHOEHUNG_DOPPELT; Wucher ⇒ 422 MIETERHOEHUNG_WUCHER; Begründung trägt nicht ⇒ 422 MIETERHOEHUNG_SCHREIBEN_UNGUELTIG; Tag vor Ende der Zustimmungsfrist ⇒ 422 MIETERHOEHUNG_VOR_ZUSTIMMUNGSFRIST; Tag in der Vergangenheit ⇒ 422 MIETERHOEHUNG_RUECKWIRKEND; fremder/unbekannter Vertrag ⇒ 404. Bei einer Abweisung wird nichts geschrieben. Ein tenantId/contractId im Body wird ignoriert.
mieterhoehung entscheiden <id>	POST	/api/mieterhoehung/{id}/entscheidung	ja	Entscheidet EINE Mieterhöhungs-Fassung: <mieterhoehungId> plus --data '{"decision":"approved"}' (freigeben) oder '{"decision":"rejected","reasonCode":"falscher-betrag"}' (ablehnen; Grund Pflicht: falscher-betrag \	falscher-kreditor \	falsche-kontierung \	kein-beleg \	doppelt \	nicht-plausibel \	sonstiges; bei approved verboten). Bindung und Inhalts-Hash bestimmt der Server selbst — der Body trägt keinen Hash. Verlangt eine frische Anmeldung (sonst 403). Ein Agent darf nicht entscheiden (403, nichts geschrieben); fremde/unbekannte Fassung ⇒ 404; verfallene oder schon entschiedene Fassung ⇒ 409.
mieterhoehung feststellen <id>	POST	/api/mieterhoehung/{id}/feststellung	ja	Stellt die Reaktion des Mieters auf ein Erhöhungsverlangen fest: <mieterhoehungId> plus --art zustimmung-ausdruecklich\	widerspruch\	sonderkuendigung und --festgestellt-am YYYY-MM-DD (oder --data). Zustimmung ⇒ Zustand "wirksam", Widerspruch/Sonderkündigung ⇒ "abgelehnt". Setzt einen Zustellnachweis voraus (sonst 409), fällt genau einmal (zweite Feststellung 409); ein Agent darf das nie (403). Der Erfasser ist der angemeldete Mensch.
mieterhoehung zahlung <id>	POST	/api/mieterhoehung/{id}/zahlung	ja	Erfasst eine beobachtete Zahlung zum Erhöhungsverlangen: <mieterhoehungId> plus --data '{"zahlungEntryId":"<uuid>","periode":"2026-03","unterVorbehalt":false}'. "unterVorbehalt" ist PFLICHT (true\	false, kein Default) — "vorbehaltlos" bestätigt ein Mensch, es wird nie aus dem Bank-Matching abgeleitet. Betrag, Währung und Datum liest der Server aus dem Buchungssatz, der eine Zahlung auf dem Mieter-Personenkonto dieses Vertrags sein muss (sonst 404). Die dritte vorbehaltlose Zahlung in drei Perioden stellt die konkludente Zustimmung fest; eine Zahlung unter Vorbehalt zählt nicht. Ohne Zustellnachweis 409.
mieterhoehung zuruecknehmen <id>	POST	/api/mieterhoehung/{id}/ruecknahme	ja	Nimmt eine wirksame Mieterhöhung zurück: <mieterhoehungId> plus --zurueckgenommen-am YYYY-MM-DD und --begruendung "<Text>" (Pflicht; oder --data). Zustand "zurueckgenommen"; die Antwort nennt "alterBetragCents", den Betrag, der wieder gilt. Nicht wirksam ⇒ 409; ein Agent darf das nie (403).
mieterhoehung indexerklaerung <id>	GET	/api/mieterhoehung/{id}/indexerklaerung	ja	Erzeugt die Erklärung einer Indexanpassung nach § 557b Abs. 3 BGB als Text im Standardwortlaut: <mieterhoehungId> eines Index-Vorgangs. Die Antwort trägt "text" (alter und neuer Index, alte und neue Miete, Rechenweg, Wirksamkeitsmonat = Beginn des übernächsten Monats nach dem Zugang), "vorlageVersion", "dokumentHash" (SHA-256 hex über den Text) und "zugangErfasst" (false = kein Zugangstag erfasst, der Wirksamkeitsmonat ist die Vorschau aus dem geplanten Wirksamkeitstag). Indexwerte und Betrag kommen aus dem gespeicherten Vorgang und werden nachgerechnet; weicht das ab ⇒ 409, kein Text. Ein § 558-Vorgang ⇒ 409 MIETERHOEHUNG_KEIN_INDEXVORGANG; fremder oder unbekannter Vorgang ⇒ 404. Nur lesend — der Text wird erzeugt, nicht versendet.
mieterhoehung versenden <id>	POST	/api/mieterhoehung/{id}/versand	ja	Versendet das freigegebene Mieterhöhungsschreiben (§ 558a BGB): <mieterhoehungId> plus --versandweg mail\	druck (mail über den Versandkanal des Mandanten, druck protokolliert nur die Übergabe) und --data '{}' (bei Ein-Personen-Mandanten --data '{"selbstfreigabeBestaetigt":true}'). Ergebnis: ausgang "zugestellt" (Zustellnachweis mit Dokument-Hash, Zustand "versendet" — nicht "wirksam") oder "fehlgeschlagen" mit fehlerCode (Zustand unverändert, erneut versendbar). Verlangt Freigabe durch eine andere Person und eine frische Anmeldung (sonst 403 MIETERHOEHUNG_VERSAND_GESPERRT, nichts versendet); ein Agent darf nicht versenden (403); schon zugegangen ⇒ 409 MIETERHOEHUNG_BEREITS_VERSENDET; fremder/unbekannter Vorgang ⇒ 404. Akteurs-Kette und Anmeldung bestimmt der Server, nie der Body.
kaution einstellung	GET	/api/kaution/einstellung	ja	Zeigt die Kaution-Einstellung des Mandanten: "rueckbehaltFristMonate" (Frist des Rückbehalts bei unklaren Forderungen, beginnt mit dem Abrechnungsdatum der Kautionsabrechnung; Vorgabe 6 Monate) und "istVorgabe" (true, solange der Mandant nichts eingestellt hat). Ändern: "kaution einstellung --monate <1…36>" (PUT, ganze Zahl; Admin-Recht nötig; wiederholungssicher mit --idempotency-key) oder "kaution einstellung setzen".
kaution einstellung setzen	PUT	/api/kaution/einstellung	ja	Setzt die Frist des Rückbehalts des Mandanten. Braucht --data '{"monate":9}' — eine ganze Zahl 1…36 (sonst 400, nichts geschrieben). Nur ein Mensch mit Admin-Recht (sonst 403). Gilt nur für neue Abrechnungen: Bestehende behalten das beim Buchen festgeschriebene Wiedervorlage-Datum. Antwort: "rueckbehaltFristMonate" (der gesetzte Wert) und "istVorgabe" (false). Wiederholungssicher mit --idempotency-key.
kaution vorschlag	POST	/api/kaution/vorschlag	ja	Berechnet den VORSCHLAG einer Kautionsbuchung, ohne zu schreiben: --art sollstellung --contractId <uuid> [--stichtag JJJJ-MM-TT] (die bis zum Stichtag fälligen Raten) oder --art eingang --bankTransactionId <uuid> --contractId <uuid> (ein Umsatz des hinterlegten Kautionskontos). Braucht --data '{}'. Die Antwort trägt den ganzen Inhalt und "vorschlagHash" — mit genau diesem Hash wird freigegeben ("kaution freigeben") und gebucht ("kaution sollstellen" / "kaution eingang"). "status" sagt, ob dieser Inhalt schon freigegeben ist.
kaution freigeben	POST	/api/kaution/freigabe	ja	Gibt einen Kautions-Vorschlag frei — gebunden an GENAU den Inhalt mit diesem Hash. Braucht --data '{}' plus dieselben Angaben wie "kaution vorschlag" (--art, --contractId, ggf. --stichtag bzw. --bankTransactionId) und --vorschlagHash <hash>. Hat sich der Inhalt seit dem Vorschlag geändert ⇒ 409 (neu vorschlagen); ohne Schreibrecht ⇒ 403; eine zweite Freigabe desselben Inhalts ⇒ 409. Ohne Freigabe buchen "kaution sollstellen" und "kaution eingang" nichts.
kaution sollstellen	POST	/api/kaution/sollstellung	ja	Stellt die bis zum Stichtag fälligen Kautionsraten eines Vertrags soll — SOLL Kautions-Personenkonto des Mieters (eigenes Debitorkonto, getrennt vom Mietkonto) / HABEN Kaution, je Rate ein Satz. Braucht --data '{}' plus --contractId <uuid> und --vorschlagHash <hash> eines FREIGEGEBENEN Vorschlags ("kaution vorschlag" → "kaution freigeben"); --stichtag JJJJ-MM-TT wie im Vorschlag (Default heute, nie in der Zukunft). Ohne gültige Freigabe (fehlt, abgelehnt, Inhalt seither geändert) ⇒ 409, nichts gebucht. Die Antwort zeigt den ganzen Ratenplan mit "status" je Rate (sollgestellt · bereits-sollgestellt · nicht-faellig); ein zweiter Aufruf bucht nichts doppelt ("neuSollgestellt": 0). Ein Vertrag ohne Kautionsabrede (übernommener Bestand) und eine Bürgschaft/Verpfändung (kein Zahlungsstrom) enden mit 409 statt einer Forderung. Cent-Felder sind Integer-STRINGS.
kaution eingang	POST	/api/kaution/eingang	ja	Verbucht einen Bankumsatz des am Vertrag hinterlegten Kautionskontos als Eingang der Kaution — Bank an Kautions-Personenkonto des Mieters, mit Buchungsanspruch und Tilgung der offenen Raten (älteste zuerst), OHNE Zuordnung zum Mietkonto. Braucht --data '{}' plus --bankTransactionId <uuid> --contractId <uuid> --vorschlagHash <hash> eines FREIGEGEBENEN Vorschlags ("kaution vorschlag --art eingang" → "kaution freigeben"); ohne gültige Freigabe ⇒ 409, nichts gebucht. Danach zeigt "kaution liste" den Betrag unter "erhaltenCents". Wiederholen bucht nichts doppelt ("replay": true). 409, wenn der Umsatz nicht auf dem hinterlegten Kautionskonto liegt, keine Abrede besteht oder die Kaution eine Bürgschaft/Verpfändung ist (kein Zahlungsstrom).
kaution festzins	PUT	/api/kaution/zinsen/festzins	ja	Pflegt den Zinssatz EINES Kautionskontos „gültig ab heute" (Eintrag der Satzhistorie mit dem heutigen Verwaltungstag). Braucht --data '{"bankAccountId":"<uuid>","basispunkte":150}' — basispunkte ist eine Zahl 0…2000 (150 = 1,50 %) oder null, um den Eintrag von heute zu löschen. Für ein anderes Datum: "kaution zinssatz setzen". Reine Stammdatenänderung ohne Buchung und ohne Freigabe. Der am Stichtag gültige Satz erscheint als "festzinsBasispunkte" in "kaution zinsstand". Nur ein Mensch; ein Konto einer anderen Art oder ein heute in einem gebuchten Zinszeitraum ⇒ 409, ein unbekanntes, fremdes oder nicht zuständiges Konto ⇒ 404, Satz außerhalb 0…2000 ⇒ 400.
kaution zinssatz liste	GET	/api/kaution/zinsen/saetze	ja	Zeigt die Satzhistorie „gültig ab" EINES Kautionskontos, aufsteigend nach "gueltigAb": je Eintrag "basispunkte" (150 = 1,50 %), "erfasstVon" ("migration" für den übernommenen Altbestand, gültig ab 1900-01-01) und "erfasstAm". Braucht --bankAccountId <uuid>. Der Satz an einem Tag ist der Eintrag mit dem größten "gueltigAb" bis zu diesem Tag; vor dem ersten Eintrag gilt kein Satz. Ein fremdes, unbekanntes oder nicht zuständiges Konto ⇒ 404 (Fehler, keine leere Liste). Nur lesend.
kaution zinssatz setzen	POST	/api/kaution/zinsen/saetze	ja	Schreibt EINEN Eintrag der Satzhistorie eines Kautionskontos. Braucht --data '{"bankAccountId":"<uuid>","gueltigAb":"2025-07-01","basispunkte":75}' — gueltigAb (JJJJ-MM-TT) ist Pflicht; ein vorhandener Eintrag desselben Tages wird überschrieben (ein wiederholter gleicher Aufruf ändert nichts), basispunkte null löscht den Eintrag dieses Tages (ohne Eintrag ⇒ 404). Ein gueltigAb in einem gebuchten Zinszeitraum des Kontos ⇒ 409, nichts geschrieben; ebenso ein Konto anderer Art ⇒ 409. Reine Stammdatenänderung ohne Buchung und ohne Freigabe. Nur ein Mensch; ein unbekanntes, fremdes oder nicht zuständiges Konto ⇒ 404, Satz außerhalb 0…2000 oder ungültiges Datum ⇒ 400.
kaution zinsen vorschlag	POST	/api/kaution/zinsen/vorschlag	ja	Berechnet den VORSCHLAG des Jahreszinslaufs eines Kautionskontos, ohne zu schreiben: der Zins je Kaution für das nächste offene Kalenderjahr (Stand zum 01.01., Zinstage, Satz bzw. Sätze, Zins), dazu die Summe. Braucht --data '{}' plus --bankAccountId <uuid> --jahr JJJJ; erlaubt ist nur "naechstesOffenesJahr" aus "kaution zinsstand" (sonst 409), ein Jahr, dessen 31.12. in der Zukunft liegt, ⇒ 400, ein Tag mit Kapital ohne Zinssatz ⇒ 409 (erst "kaution zinssatz setzen"). Die Antwort trägt "vorschlagHash" und "status". Hash-Ablauf: der Vorschlag selbst verlangt keinen Hash, er liefert ihn. Erst die Folgebefehle (kaution zinsen freigeben, ein Mensch mit Schreibrecht, kein Vier-Augen-Prinzip, dann kaution zinsen buchen) verlangen --vorschlagHash und brechen ohne ihn ab, nichts wird gesendet; ein falscher oder nicht freigegebener Hash ⇒ 409 (Code conflict), nichts gebucht.
kaution zinsen freigeben	POST	/api/kaution/zinsen/freigabe	ja	Gibt den Zinsjahr-Vorschlag frei — gebunden an GENAU den Inhalt mit diesem Hash. Braucht --data '{}' plus --bankAccountId --jahr wie im Vorschlag und --vorschlagHash <hash>. Hash-Ablauf: erst den Vorschlag holen (kaution zinsen vorschlag), dann freigeben (kaution zinsen freigeben, ein Mensch mit Schreibrecht, kein Vier-Augen-Prinzip), dann mit genau diesem --vorschlagHash ausführen. Ohne --vorschlagHash bricht die CLI ab, nichts wird gesendet; ein falscher oder nicht freigegebener Hash ⇒ 409 (Code conflict), nichts gebucht.
kaution zinsen buchen	POST	/api/kaution/zinsen/buchung	ja	Bucht das FREIGEGEBENE Zinsjahr: je Kaution ein Satz zum 31.12. SOLL 1481 Zinsforderung Kautionskonto an HABEN Kautions-Personenkonto (kein Bankumsatz-Anspruch). Braucht --data '{}' plus --bankAccountId --jahr und --vorschlagHash. Wiederholen bucht nichts doppelt ("neuGebucht"). Hash-Ablauf: erst den Vorschlag holen (kaution zinsen vorschlag), dann freigeben (kaution zinsen freigeben, ein Mensch mit Schreibrecht, kein Vier-Augen-Prinzip), dann mit genau diesem --vorschlagHash ausführen. Ohne --vorschlagHash bricht die CLI ab, nichts wird gesendet; ein falscher oder nicht freigegebener Hash ⇒ 409 (Code conflict), nichts gebucht.
kaution zinsen gutschrift vorschlag	POST	/api/kaution/zinsen/vorschlag	ja	Berechnet den VORSCHLAG der Zuordnung einer Bankgutschrift zu einem Zinsjahr (Art gutschrift), ohne zu schreiben. Braucht --data '{}' plus --bankTransactionId <uuid> (Haben-Umsatz auf einem Kautionskonto, Zinsgutschrift der Bank; kein Haben-Umsatz oder falsche Kontoart ⇒ 409, fremder oder unbekannter Umsatz ⇒ 404). OHNE --jahr JJJJ listet die Antwort die Jahre mit offenem Saldo auf dem Konto 1481 Zinsforderung ("offeneJahre", mit "saldoCents"); mit --jahr (eines der offenen Jahre, sonst 409) liefert sie Differenz und Anteile: Mehrbetrag der Bank über dem Saldo geht an die Mieter nach Guthaben × Tagen ("mehrbetragCents" je Kaution; bei einer schon ausgezahlten Kaution ab 1,00 € zusätzlich als Zahlungsauftrag zur Freigabe an den gespeicherten Empfänger der Kautionsauszahlung, darunter trägt der Vermieter den Anteil auf 58600), Minderbetrag trägt der Vermieter auf 58600, bei gleichem Betrag wird nur Bank an 1481 gebucht. Die Antwort trägt "vorschlagHash" und "status". Hash-Ablauf: der Vorschlag selbst verlangt keinen Hash, er liefert ihn. Erst die Folgebefehle (kaution zinsen gutschrift freigeben, ein Mensch mit Schreibrecht, kein Vier-Augen-Prinzip, dann kaution zinsen gutschrift buchen) verlangen --vorschlagHash und brechen ohne ihn ab, nichts wird gesendet; ein falscher oder nicht freigegebener Hash ⇒ 409 (Code conflict), nichts gebucht.
kaution zinsen gutschrift freigeben	POST	/api/kaution/zinsen/freigabe	ja	Gibt die Zuordnung der Bankgutschrift zu einem Zinsjahr frei — gebunden an GENAU den Inhalt mit diesem Hash. Braucht --data '{}' plus --bankTransactionId --jahr wie im Vorschlag und --vorschlagHash <hash>. Hash-Ablauf: erst den Vorschlag holen (kaution zinsen gutschrift vorschlag --jahr JJJJ), dann freigeben (kaution zinsen gutschrift freigeben, ein Mensch mit Schreibrecht, kein Vier-Augen-Prinzip), dann mit genau diesem --vorschlagHash ausführen. Ohne --vorschlagHash bricht die CLI ab, nichts wird gesendet; ein falscher oder nicht freigegebener Hash ⇒ 409 (Code conflict), nichts gebucht.
kaution zinsen gutschrift buchen	POST	/api/kaution/zinsen/buchung	ja	Bucht die FREIGEGEBENE Zuordnung der Bankgutschrift zu einem Zinsjahr: EIN Satz Bank an 1481 in Höhe des offenen Saldos, der Mehrbetrag an die Kautions-Personenkonten (Guthaben × Tage; schon ausgezahlte Kaution ab 1,00 € zusätzlich als Zahlungsauftrag zur Freigabe, darunter 58600), ein Minderbetrag 58600 an 1481. Der Bankumsatz wird beansprucht: derselbe Umsatz ein zweites Mal ⇒ 409, nichts gebucht. Braucht --data '{}' plus --bankTransactionId --jahr und --vorschlagHash. Hash-Ablauf: erst den Vorschlag holen (kaution zinsen gutschrift vorschlag --jahr JJJJ), dann freigeben (kaution zinsen gutschrift freigeben, ein Mensch mit Schreibrecht, kein Vier-Augen-Prinzip), dann mit genau diesem --vorschlagHash ausführen. Ohne --vorschlagHash bricht die CLI ab, nichts wird gesendet; ein falscher oder nicht freigegebener Hash ⇒ 409 (Code conflict), nichts gebucht.
kaution zinsen storno vorschlag	POST	/api/kaution/zinsen/storno	ja	Berechnet den VORSCHLAG des Stornos des ZULETZT gebuchten Zinsjahres eines Kautionskontos, ohne zu schreiben: je Kaution der Jahreszinssatz, der gegengebucht würde, die Summe und die Generation. Braucht --data '{}' plus --bankAccountId <uuid> --jahr JJJJ --grund <Text, 1 bis 500 Zeichen, Pflicht>. Nur das zuletzt gebuchte Jahr (sonst 409), nur ohne zugeordnete Bankgutschrift (sonst 409) und ohne abgerechnete Kaution (sonst 409); ein fremdes oder unbekanntes Konto => 404. Die Antwort trägt "vorschlagHash" und "status". Hash-Ablauf: der Vorschlag selbst verlangt keinen Hash, er liefert ihn. Erst die Folgebefehle (kaution zinsen storno freigeben, ein Mensch mit Schreibrecht, kein Vier-Augen-Prinzip, dann kaution zinsen storno ausfuehren) verlangen --vorschlagHash und brechen ohne ihn ab, nichts wird gesendet; ein falscher oder nicht freigegebener Hash => 409 (Code conflict), nichts storniert.
kaution zinsen storno freigeben	POST	/api/kaution/zinsen/storno	ja	Gibt den Storno-Vorschlag des Zinsjahres frei — gebunden an GENAU den Inhalt mit diesem Hash (Artefakt-Art kautionszinsjahr-storno). Braucht --data '{}' plus --bankAccountId --jahr --grund wie im Vorschlag und --vorschlagHash <hash>. Hash-Ablauf: erst den Vorschlag holen (kaution zinsen storno vorschlag), dann freigeben (kaution zinsen storno freigeben, ein Mensch mit Schreibrecht, kein Vier-Augen-Prinzip), dann mit genau diesem --vorschlagHash ausführen (kaution zinsen storno ausfuehren). Ohne --vorschlagHash bricht die CLI ab, nichts wird gesendet; ein falscher oder nicht freigegebener Hash => 409 (Code conflict), nichts gebucht.
kaution zinsen storno ausfuehren	POST	/api/kaution/zinsen/storno	ja	Storniert das FREIGEGEBENE Zinsjahr: je Kaution die Gegenbuchung des Jahreszinssatzes; danach ist das Jahr wieder das nächste offene Zinsjahr und bucht unter der nächsten Generation neu. Ein zweiter Aufruf bucht nichts ("neuStorniert": 0). Ein Jahr, das ohne Zins gebucht war (Nullzins-Marke), hat nichts zum Gegenbuchen: der Storno öffnet es trotzdem wieder ("neuStorniert": 0, "nullzinsjahr": true). Braucht --data '{}' plus --bankAccountId --jahr --grund und --vorschlagHash. Hash-Ablauf: erst den Vorschlag holen (kaution zinsen storno vorschlag), dann freigeben (kaution zinsen storno freigeben, ein Mensch mit Schreibrecht, kein Vier-Augen-Prinzip), dann mit genau diesem --vorschlagHash ausführen (kaution zinsen storno ausfuehren). Ohne --vorschlagHash bricht die CLI ab, nichts wird gesendet; ein falscher oder nicht freigegebener Hash => 409 (Code conflict), nichts gebucht.
kaution zinsen liste	GET	/api/kaution/zinsen	ja	Listet die gebuchten Zinsgutschriften eines Vertrags. Braucht --contractId <uuid>.
kaution abrechnung vorschlag	POST	/api/kaution/abrechnung/vorschlag	ja	Berechnet den VORSCHLAG einer Kautionsabrechnung (--art abrechnung), einer Rückbehalt-Freigabe (--art rueckbehalt) oder eines Stornos (--art storno), ohne zu schreiben. Der Body hängt von --art ab: abrechnung = --contractId --stichtag --requestedExecutionDate JJJJ-MM-TT (die anteiligen Zinsen vom 01.01. bis zum Abrechnungstag rechnet die Abrechnung selbst und bucht sie mit der Abrechnung auf 1481; fehlt das Zinsjahr des Vorjahres ⇒ 409, erst den Zinslauf ausführen; liegt der Abrechnungstag in einem gebuchten Zinsjahr ⇒ 409, erst das Zinsjahr stornieren) und --data '{"offenePostenIds":[…],"rueckbehalte":[{"grundart":"bk-nachzahlung","betragCents":"…"},{"grundart":"sonstiges","betragCents":"…","begruendung":"…"}]}' (rueckbehalte optional: bk-nachzahlung höchstens einmal, gedeckelt auf die letzte BK-Nachzahlung ohne Aufschlag, bei letztem Guthaben nicht wählbar; sonstiges beliebig oft, frei bis zum Guthaben, Begründung Pflicht); rueckbehalt = --contractId --stichtag --requestedExecutionDate, offenePostenIds in --data, optional --betragCents <Ziffern> für einen Teilbetrag; storno = --kautionsabrechnungId --grund. Die Antwort trägt "vorschlagHash", "status" und den ganzen Inhalt. Hash-Ablauf: der Vorschlag selbst verlangt keinen Hash, er liefert ihn. Erst die Folgebefehle (kaution abrechnung freigeben, ein Mensch mit Schreibrecht, kein Vier-Augen-Prinzip, dann kaution abrechnung ausfuehren bzw. storno bzw. kaution rueckbehalt-freigeben) verlangen --vorschlagHash und brechen ohne ihn ab, nichts wird gesendet; ein falscher oder nicht freigegebener Hash ⇒ 409 (Code conflict), nichts gebucht. Optional --empfaengerBankverbindungId <uuid> wählt den Empfänger der Auszahlung aus den bestätigten Bankverbindungen der Mieter des Vertrags (nur bei art abrechnung; genau eine wählbare Verbindung wird vorbelegt, bei mehreren ohne Wahl steht der Vorschlag auf Zustand empfaenger-offen und Freigabe bzw. Ausführung brechen mit 409 ab; eine nicht bestätigte oder fremde Verbindung ⇒ 409). Der Vorschlag nennt alle waehlbareEmpfaenger; die Wahl ist Teil des Hashs und gilt auch für spätere Rückbehalt-Freigaben.
kaution abrechnung freigeben	POST	/api/kaution/abrechnung/freigabe	ja	Gibt den Abrechnungs-, Rückbehalt- oder Storno-Vorschlag frei — gebunden an GENAU den Inhalt mit diesem Hash. Braucht --data und dieselben Angaben wie "kaution abrechnung vorschlag" (--art …) plus --vorschlagHash. Der Body hängt von --art ab: abrechnung = --contractId --stichtag --requestedExecutionDate (die Zinsen rechnet die Abrechnung selbst, keine Eingabe) und --data '{"offenePostenIds":[…],"rueckbehalte":[{"grundart":"bk-nachzahlung","betragCents":"…"},{"grundart":"sonstiges","betragCents":"…","begruendung":"…"}]}' (rueckbehalte optional: bk-nachzahlung höchstens einmal, gedeckelt auf die letzte BK-Nachzahlung ohne Aufschlag, bei letztem Guthaben nicht wählbar; sonstiges beliebig oft, frei bis zum Guthaben, Begründung Pflicht); rueckbehalt = --contractId --stichtag, offenePostenIds in --data, ggf. derselbe --betragCents wie im Vorschlag; storno = --kautionsabrechnungId --grund. Hash-Ablauf: erst den Vorschlag holen (kaution abrechnung vorschlag), dann freigeben (kaution abrechnung freigeben, ein Mensch mit Schreibrecht, kein Vier-Augen-Prinzip), dann mit genau diesem --vorschlagHash ausführen. Ohne --vorschlagHash bricht die CLI ab, nichts wird gesendet; ein falscher oder nicht freigegebener Hash ⇒ 409 (Code conflict), nichts gebucht. Optional --empfaengerBankverbindungId <uuid> wählt den Empfänger der Auszahlung aus den bestätigten Bankverbindungen der Mieter des Vertrags (nur bei art abrechnung; genau eine wählbare Verbindung wird vorbelegt, bei mehreren ohne Wahl steht der Vorschlag auf Zustand empfaenger-offen und Freigabe bzw. Ausführung brechen mit 409 ab; eine nicht bestätigte oder fremde Verbindung ⇒ 409). Der Vorschlag nennt alle waehlbareEmpfaenger; die Wahl ist Teil des Hashs und gilt auch für spätere Rückbehalt-Freigaben.
kaution abrechnung ausfuehren	POST	/api/kaution/abrechnung	ja	Führt die FREIGEGEBENE Kautionsabrechnung aus: verrechnet offene Posten, behält ggf. zurück und legt die Auszahlung als Zahlungsauftrag zur Freigabe an (die CLI zahlt nichts selbst aus). Braucht --contractId --stichtag --requestedExecutionDate (die Zinsen bis zum Abrechnungstag rechnet die Abrechnung selbst), --data '{"offenePostenIds":[…]}' (ggf. mit rueckbehalte) und --vorschlagHash des Vorschlags mit --art abrechnung. Hash-Ablauf: erst den Vorschlag holen (kaution abrechnung vorschlag --art abrechnung), dann freigeben (kaution abrechnung freigeben --art abrechnung, ein Mensch mit Schreibrecht, kein Vier-Augen-Prinzip), dann mit genau diesem --vorschlagHash ausführen. Ohne --vorschlagHash bricht die CLI ab, nichts wird gesendet; ein falscher oder nicht freigegebener Hash ⇒ 409 (Code conflict), nichts gebucht. Optional --empfaengerBankverbindungId <uuid> wählt den Empfänger der Auszahlung aus den bestätigten Bankverbindungen der Mieter des Vertrags (nur bei art abrechnung; genau eine wählbare Verbindung wird vorbelegt, bei mehreren ohne Wahl steht der Vorschlag auf Zustand empfaenger-offen und Freigabe bzw. Ausführung brechen mit 409 ab; eine nicht bestätigte oder fremde Verbindung ⇒ 409). Der Vorschlag nennt alle waehlbareEmpfaenger; die Wahl ist Teil des Hashs und gilt auch für spätere Rückbehalt-Freigaben.
kaution abrechnung storno	POST	/api/kaution/abrechnung/storno	ja	Storniert eine ausgeführte Kautionsabrechnung (Verrechnungen werden gegengebucht, offene Zahlungsaufträge storniert). Braucht --data '{}' plus --kautionsabrechnungId <uuid> --grund <text> (Pflicht, ≤ 500 Zeichen) und --vorschlagHash des Vorschlags mit --art storno. Hash-Ablauf: erst den Vorschlag holen (kaution abrechnung vorschlag --art storno), dann freigeben (kaution abrechnung freigeben --art storno; kein Vier-Augen-Prinzip: dieselbe Person darf abrechnen, freigeben und ausführen, die Freigabe selbst muss ein Mensch mit Schreibrecht erteilen), dann mit genau diesem --vorschlagHash ausführen. Ohne --vorschlagHash bricht die CLI ab, nichts wird gesendet; ein falscher oder nicht freigegebener Hash ⇒ 409 (Code conflict), nichts gebucht.
kaution rueckbehalt-freigeben	POST	/api/kaution/rueckbehalt-freigabe	ja	Gibt den bei der Abrechnung einbehaltenen Rückbehalt frei: verrechnet jetzt fällige Posten (z. B. die BK-Nachzahlung) und legt die Auszahlung als Zahlungsauftrag zur Freigabe an. Braucht --contractId --stichtag --requestedExecutionDate JJJJ-MM-TT, --data '{"offenePostenIds":[…]}' und --vorschlagHash des Vorschlags mit --art rueckbehalt. Optional --betragCents <Ziffern> gibt nur einen TEILBETRAG in Cent frei (Ziffern-String, 0 < Teilbetrag ≤ Rest, sonst 409): der Rückbehalt ist danach teilfreigegeben mit Rest, der letzte Schritt (Rest 0) gibt ihn ganz frei; ohne --betragCents wird der ganze Rest freigegeben. Jeder Teilschritt braucht seinen eigenen Vorschlag und seine eigene Freigabe mit demselben --betragCents. Hash-Ablauf: erst den Vorschlag holen (kaution abrechnung vorschlag --art rueckbehalt), dann freigeben (kaution abrechnung freigeben --art rueckbehalt, ein Mensch mit Schreibrecht, kein Vier-Augen-Prinzip), dann mit genau diesem --vorschlagHash ausführen. Ohne --vorschlagHash bricht die CLI ab, nichts wird gesendet; ein falscher oder nicht freigegebener Hash ⇒ 409 (Code conflict), nichts gebucht.
konto list	GET	/api/konto	ja	Listet Konten. --status alle\	aktiv\	archiviert (Default aktiv), --propertyId <uuid> grenzt auf ein Objekt ein.
konto get <id>	GET	/api/konto/{id}	ja	Liest EIN Konto samt Kostenkategorie.
konto create	POST	/api/konto	ja	Legt ein Konto an (propertyId, accountNo, name). Braucht --data <json>.
bank list	GET	/api/bank	ja	Listet Bankverbindungen. --status alle\	aktiv\	archiviert (Default aktiv), --propertyId <uuid> grenzt auf ein Objekt ein.
bank get <id>	GET	/api/bank/{id}	ja	Liest EINE Bankverbindung.
bank create	POST	/api/bank	ja	Legt eine Bankverbindung an (propertyId, iban, kind). Braucht --data <json>.
bank update <id>	PATCH	/api/bank/{id}	ja	Ändert Bankverbindungs-Stammfelder (iban/kind/glaeubigerId). Braucht --data <json>.
bank archive <id>	POST	/api/bank/{id}/archive	ja	Archiviert eine Bankverbindung (archived_at statt Löschen).
bank umsatz-import <id> <datei>	POST	/api/bank/{id}/umsatz-import	ja	Importiert einen Kontoauszug (Datei) auf eine Bankverbindung. --format camt.053\	camt.052\	mt940 wählt nur den Parser; verbucht wird das aus der Datei ERKANNTE Format. Die Datei wird serverseitig geparst; eine Wiederholung ist gefahrlos (Dedup).
bankzugang list	GET	/api/bankzugang	ja	Listet die Bankzugänge (BANKSapi) des Mandanten samt Status — ohne Anbieter-Zugangsdaten.
person list	GET	/api/person	ja	Listet Personen. --status alle\	aktiv\	archiviert (Default aktiv).
person get <id>	GET	/api/person/{id}	ja	Liest EINE Person.
person create	POST	/api/person	ja	Legt eine Person an. Braucht --data <json>.
konto update <id>	PATCH	/api/konto/{id}	ja	Ändert Konto-Stammfelder (nach Erstbuchung nur den Namen). Braucht --data <json>.
person update <id>	PATCH	/api/person/{id}	ja	Ändert Personen-Stammfelder. Braucht --data <json>.
konto archive <id>	POST	/api/konto/{id}/archive	ja	Archiviert ein Konto (archived_at statt Löschen).
konto umlageschluessel <id>	POST	/api/konto/{id}/umlageschluessel	ja	Ordnet dem Konto einen Umlageschlüssel zu: --schluessel <uuid> (oder --data '{"allocationKeyId":null}' zum Aufheben). Fremdes Objekt/Tenant ⇒ Fehler.
kontenrahmen list	GET	/api/kontenrahmen	ja	Listet die verfügbaren Musterkontenrahmen.
kontenrahmen apply <id>	POST	/api/kontenrahmen/{id}/apply	ja	Spielt einen Musterkontenrahmen auf ein Objekt ein (wiederholbar, legt nichts doppelt an). Braucht --data '{"propertyId":"…"}'.
person archive <id>	POST	/api/person/{id}/archive	ja	Archiviert eine Person (archived_at statt Löschen). Rollen bleiben unberührt.
rolle list	GET	/api/rolle	ja	Listet Rollen. --status alle\	aktiv\	beendet (Default aktiv), --person <uuid>, --asOf <YYYY-MM-DD>.
rolle assign	POST	/api/rolle	ja	Vergibt einer Person eine Rolle an Objekt ODER Einheit. Braucht --data <json>.
rolle end <id>	POST	/api/rolle/{id}/end	ja	Beendet eine Rolle zum Stichtag. Braucht --data '{"endDate":"YYYY-MM-DD"}'.
gebaeude list	GET	/api/gebaeude	ja	Listet Gebäude. --status alle\	aktiv\	archiviert (Default aktiv), --objektId <uuid>.
gebaeude get <id>	GET	/api/gebaeude/{id}	ja	Liest EIN Gebäude samt Objektbezug.
gebaeude create	POST	/api/gebaeude	ja	Legt ein Gebäude an einem aktiven Objekt an. Braucht --data <json> mit propertyId.
gebaeude update <id>	PATCH	/api/gebaeude/{id}	ja	Ändert die Gebäude-Adresse. Braucht --data <json>. (propertyId ist nicht änderbar.)
gebaeude archive <id>	POST	/api/gebaeude/{id}/archive	ja	Archiviert ein Gebäude (archived_at statt Löschen; kaskadiert auf alle Einheiten des Gebäudes).
einheit list	GET	/api/einheit	ja	Listet Einheiten. --status alle\	aktiv\	archiviert (Default aktiv), --gebaeudeId/--objektId <uuid>.
einheit get <id>	GET	/api/einheit/{id}	ja	Liest EINE Einheit samt Gebäude- und Objektbezug.
einheit wechselzeitraum <id>	GET	/api/einheit/{id}/wechselzeitraum	ja	Vorabprüfung: passt ein nachträglich zu erfassender früherer Bewohner- oder Eigentümerzeitraum in den Bestand der Einheit? Schreibt nichts. Pflicht: --art bewohner\	eigentuemer --von JJJJ-MM-TT --bis JJJJ-MM-TT; beide Tage sind inklusive. Ergebnis "code": ok \	ueberlappt (mit der betroffenen Zeile, auch wenn das Ende auf den Beginn des bestehenden Zeitraums fällt) \	zeitraum-verdreht \	beginn-unbekannt. Die Lücke zum nächsten bestehenden Zeitraum wird gemeldet, aber nicht verboten. Erfasst wird über die Belegungs- und Eigentumskommandos.
einheit create	POST	/api/einheit	ja	Legt eine Einheit an einem aktiven Gebäude an. Braucht --data <json> mit buildingId, unitNo (je Objekt eindeutig), unitKind, bezeichnung.
einheit update <id>	PATCH	/api/einheit/{id}	ja	Ändert unitNo/unitKind/bezeichnung. Braucht --data <json>. (buildingId ist nicht änderbar.)
einheit archive <id>	POST	/api/einheit/{id}/archive	ja	Archiviert eine Einheit (archived_at statt Löschen).
einheit attribut list <id>	GET	/api/einheit/{id}/attribut	ja	Liest die Attribut-Historie einer Einheit. --attributeKey <key>, --asOf <YYYY-MM-DD>.
einheit attribut set <id>	POST	/api/einheit/{id}/attribut	ja	Setzt/ändert eine Attribut-Zeitscheibe ab Datum. --ab <YYYY-MM-DD> und --data '{"attributeKey":"flaeche","attributeValue":{…}}'.
einheit sev-mandat list <id>	GET	/api/einheit/{id}/sev-mandat	ja	Liest die Sondereigentumsverwaltung einer Einheit. OHNE Flags: das zum HEUTIGEN Stichtag wirksame Mandat (mandat: null heisst „am Stichtag keine SEV" — kein Fehler). --stichtag <YYYY-MM-DD> fragt einen anderen Tag, --historie 1 liefert alle Zeitabschnitte.
einheit sev-mandat anlegen <id>	POST	/api/einheit/{id}/sev-mandat	ja	Vereinbart die Sondereigentumsverwaltung für einen Eigentümer und diese Einheit. --ab <YYYY-MM-DD> und --data '{"personId":"…","mitMietinkasso":true,"mietgutschriftBasis":"ist","verguetungVermietet":{"art":"prozent","prozentSkaliert":"55000"},"verguetungLeerstand":{"art":"festbetrag","betragCents":"1500"},"hausgeldQuelle":"weg_soll","sonderruecklageRegel":"keine","auszahlungRhythmus":"quartalsweise","sockelbetragCents":"50000","eigentuemerBankkontoId":"…"}'. Geld und Prozent sind ZIFFERN-STRINGS (1 % = "10000"). Nur im PRO-Objekt möglich; die Person muss im ganzen Zeitraum Eigentümerin der Einheit sein.
sev-mandat beenden <id>	POST	/api/sev-mandat/{id}/beenden	ja	Beendet einen SEV-Zeitabschnitt. --data '{"endeExklusiv":"2025-07-01"}' — endeExklusiv ist der erste Tag OHNE Sondereigentumsverwaltung: „zum 30.06. beendet" ⇒ 2025-07-01. Beenden KÜRZT nur — die Historie bleibt stehen, damit eine abgerechnete Periode erklärbar bleibt; dasselbe Ende ein zweites Mal ist ein Erfolg ohne Änderung.
sev-mandat eigentuemerabrechnung <id>	GET	/api/sev-mandat/{id}/eigentuemerabrechnung	ja	Liest die Jahresabrechnung der Sondereigentumsverwaltung für den Eigentümer: Einnahmen, Ausgaben und Auszahlungen je Buchungsart, Mieteinnahmen (Soll, Ist, Ausfall, Ertrag je m²), Kosten der Wohnung und die Entwicklung des Geldbestands mit Probe gegen das Verrechnungskonto, dazu der Empfänger mit Anrede und Anschrift. --von <YYYY-MM-DD> und --bis <YYYY-MM-DD> sind Pflicht (beide inklusiv); --mitAuszahlung false blendet die Auszahlungs-Positionen aus (Summe und Geldbestand bleiben). Ein Mandat ohne Mietinkasso hat keine Abrechnung; ein Eigentümer ohne Anschrift ist ein Fehler, kein leeres Adressfeld.
objekt eigentum list <id>	GET	/api/objekt/{id}/eigentum	ja	Liest das Eigentum eines Objekts zum Stichtag, je Einheit, mit Anteilssumme und Befund "anteilssumme_ungleich_10000". Pflicht: --stichtag <YYYY-MM-DD> (keine Server-Uhr). Optional --einheit <uuid> (nur diese Einheit) und --historie 1 (auch abgelaufene und künftige Zeilen; "istGegenwart" markiert die am Stichtag wirksamen). Anteile in Zehntausendsteln. Die Zustellanschrift steht nie in der Antwort, nur "hatZustellanweisung". Fremdes oder unbekanntes Objekt bzw. Einheit ist not_found.
einheit eigentum anlegen <id>	POST	/api/einheit/{id}/eigentum	ja	Erfasst eine Eigentumszeile an der Einheit. Pflicht: --person <personId>, --anteil <Zehntausendstel als Integer-String, > 0, z. B. 5000 = 50 %>, --von <YYYY-MM-DD>. Optional --bis <YYYY-MM-DD> (erster Tag OHNE Eigentum; ohne: unbefristet). Zustellanschrift, Vollmacht, Anschreiben-Empfänger und Umsatzsteuer-Option über --data '{"zustellanweisung":{"empfaengerName":"…","adresse":"…"},"bevollmaechtigung":{"personId":"…","fenster":{"von":"2026-01-01"}},"anschreibenEmpfaenger":true,"ustOption":false}'. Ein Eigentümerwechsel im Jahr ist KEIN anlegen+beenden, sondern casa einheit eigentuemerwechsel. Nur in WEG- und PRO-Objekten.
eigentum beenden <id>	POST	/api/eigentum/{id}/beenden	ja	Beendet eine Eigentumszeile (die Id ist die ownershipId aus casa objekt eigentum list). Pflicht: --ende <YYYY-MM-DD> — der erste Tag OHNE Eigentum: "zum 30.06. beendet" ⇒ 2025-07-01. Beenden KÜRZT nur das Zeitfenster, die Historie bleibt; dasselbe Ende ein zweites Mal ist ein Erfolg ohne Änderung ("beendet": false). Es gibt kein Löschen. Für einen Eigentümerwechsel casa einheit eigentuemerwechsel nehmen.
einheit eigentuemerwechsel <id>	POST	/api/einheit/{id}/eigentuemerwechsel	ja	Erfasst einen Eigentümerwechsel als EINEN Vorgang: die abgehenden Eigentumszeilen enden am Stichtag, die neuen beginnen an ihm. Der Stichtag ist die Eintragung im Grundbuch, Abteilung I — NICHT der Notartermin: --grundbuch <YYYY-MM-DD>. Optional --zustimmung <YYYY-MM-DD> (Verwalterzustimmung). Abgehende und neue Zeilen über --data '{"abgehend":[{"ownershipId":"…"}],"neu":[{"personId":"…","anteil":"10000"}]}' (Anteile in Zehntausendsteln als Integer-String; je neue Zeile optional zustellanweisung, bevollmaechtigung, anschreibenEmpfaenger, ustOption). Laufende SEV-Mandate abgehender Eigentümer werden NICHT beendet, sondern in "sevMandateOffen" genannt. Bisherige Wechsel: casa einheit eigentuemerwechsel list <einheitId>.
einheit eigentuemerwechsel list <id>	GET	/api/einheit/{id}/eigentuemerwechsel	ja	Listet die Eigentümerwechsel einer Einheit, aufsteigend nach Grundbuch-Stichtag, mit Verwalterzustimmung sowie den abgehenden und neuen Eigentumszeilen (ownershipIds). Eine Einheit ohne Wechsel ist eine leere Liste, kein Fehler.
objekt beschluss list <id>	GET	/api/objekt/{id}/beschluss	ja	Liest die Beschluss-Sammlung eines Objekts (§ 24 Abs. 7 WEG). OHNE --status: die VOLLSTÄNDIGE Sammlung. --status <a,b,…> filtert (angenommen, abgelehnt, angefochten, bestandskraeftig, aufgehoben, nichtig); ein unbekannter Wert ist ein Fehler, keine leere Liste.
objekt beschluss erfassen <id>	POST	/api/objekt/{id}/beschluss	ja	Erfasst EINEN Beschluss samt Teil-Gegenständen — auch der Weg des WinCASA-Alt-Imports. --data '{"lfdNr":14,"thema":"…","quelle":"alt_import","gegenstaende":[{"lfdNr":1,"bezeichnung":"…","wpGegenstaende":["vorschuesse","ruecklagenzufuehrung"],"wpFortgeltung":true}]}'. wpGegenstaende/wpFortgeltung (nur mit vorschuesse) machen den Teil zum Träger eines Wirtschaftsplans. Ein Änderungs-Kommando gibt es bewusst nicht: Korrektur ist ein Zweitbeschluss.
objekt beschluss import <id> <datei>	POST	/api/objekt/{id}/beschluss/import	ja	Importiert einen WinCASA-Beschlussbestand in die Sammlung eines Objekts (Export der Tabelle VERTHEMEN bzw. VERSAMMLUNG_ERG, serverseitig geparst). Braucht --onr <objektnummer-im-altbestand>. Der Bericht nennt die BEFUNDE je Zeile — u. a. wenn die überlieferten Zählwerte dem übernommenen Status widersprechen; dieselben Befunde stehen dauerhaft im Import-Vermerk des Beschlusses. Teilerfolg ist erlaubt: abgewiesene Zeilen stehen benannt im Bericht. Ein zweiter Lauf derselben Datei legt nichts doppelt an — nicht durch Idempotenz (der CLI-Lauf prägt je Aufruf einen frischen Schlüssel), sondern weil die laufende Nummer je Objekt eindeutig ist; die bereits importierten Zeilen erscheinen dann unter „fehlgeschlagen".
objekt versammlung list <id>	GET	/api/objekt/{id}/versammlung	ja	Liest die Versammlungen (und Umlaufbeschlüsse) eines Objekts, jüngstes Versammlungsdatum zuerst. Beim Umlaufbeschluss werden Stimmprinzip und Beschlussfähigkeit nicht ausgewiesen.
objekt versammlung anlegen <id>	POST	/api/objekt/{id}/versammlung	ja	Legt eine Versammlung (--art ordentlich \	ausserordentlich) oder einen Umlaufbeschluss (--art umlauf) für ein Objekt an. --datum <YYYY-MM-DD> ist das Versammlungsdatum (beim Umlaufbeschluss das Datum der Beschlussfassung), --einladung <YYYY-MM-DD> das Einladungsdatum, --begruendung <text> die Begründung einer verkürzten Einladungsfrist, --stimmprinzip koepfe (Default) \	mea \	objekt; weitere Felder per --data (beschlussfaehig, beschlussfaehigkeitNotiz). Liegt die Einladung weniger als 3 Wochen (21 Tage) vor der Versammlung, gibt es eine Warnung (Feld hinweise) und die Begründung ist Pflicht — aber keine Sperre: mit Begründung wird gespeichert. Ohne Einladungsdatum wird gespeichert, Hinweis einladung-nicht-erfasst. Der Umlaufbeschluss ist nur eine Art: kein Einladungsdatum, keine Teilnehmer, kein Stimmprinzip; die Abstimmung läuft nicht über casa.ai.
versammlung get <id>	GET	/api/versammlung/{id}	ja	Liest EINE Versammlung: Art, Status, Termine, Einladungsfrist-Begründung, Stimmprinzip und Beschlussfähigkeit (beim Umlaufbeschluss nicht ausgewiesen; sie wird nie berechnet, sondern wie gespeichert gezeigt), das Ende der Anfechtungsfrist, sobald verkündet wurde, sowie Tagesordnung (tops), Teilnehmer (teilnehmer), summeStimmgewicht und anzahlTeilnehmer.
versammlung aendern <id>	PATCH	/api/versammlung/{id}	ja	Ändert eine Versammlung: --datum, --einladung, --begruendung, --stimmprinzip, --status durchgefuehrt \	abgesagt (nur entwurf → durchgefuehrt und entwurf\	durchgefuehrt → abgesagt; „abgeschlossen“ setzt allein das Generieren der Beschlüsse). art und Objekt sind nicht änderbar. Einladungsfrist unter 3 Wochen: Warnung (Feld hinweise), Begründung Pflicht, keine Sperre. Sind die Beschlüsse generiert, ist die Versammlung unveränderlich (Konflikt).
versammlung top <id>	POST	/api/versammlung/{id}/tops	ja	Erfasst einen Tagesordnungspunkt: --bezeichnung <text> (Pflicht), --art beschluss (Default) \	geschaeftsordnung \	notiz, --text <beschlusstext>; weitere Felder per --data (kategorie). Die laufende TOP-Nummer vergibt der Server als nächste freie je Versammlung. Beim Umlaufbeschluss genau ein TOP. Ist die Versammlung abgeschlossen (Beschlüsse generiert), gibt es einen Konflikt.
versammlung top-aendern <id> <topId>	PATCH	/api/versammlung/{id}/tops/{topId}	ja	Ändert Text und Art eines Tagesordnungspunkts: --bezeichnung, --art beschluss \	geschaeftsordnung \	notiz, --text <beschlusstext>; weitere Felder per --data (kategorie). Die laufende Nummer (Reihenfolge) ist nicht änderbar. Die Art eines TOP mit Ergebnis oder Beschluss bleibt beschluss.
versammlung teilnehmer <id>	POST	/api/versammlung/{id}/teilnehmer	ja	Setzt einen Teilnehmer mit Stimmrecht (Upsert je Person: erneutes Setzen überschreibt; ein Entfernen gibt es nicht, wer nicht erschienen ist, wird nicht erfasst): --person <personId> und --anwesenheit praesent \	online \	vertreten sind Pflicht, --gewicht <ganze Zahl> das Stimmgewicht (Stimmprinzip koepfe: nur 1 und Default; mea: Zehntausendstel, Pflicht; objekt: Anzahl der Einheiten, Pflicht), --vertreten-durch <text>. Ob die Person Eigentümer des Objekts ist, prüft casa.ai nicht — Gäste, Vertreter und Verwalter sind Teilnehmer. Die Person muss zum Mandanten gehören. Beim Umlaufbeschluss gibt es keine Teilnehmer. Die Beschlussfähigkeit wird nicht berechnet (casa versammlung aendern --data).
versammlung ergebnis <id> <topId>	POST	/api/versammlung/{id}/tops/{topId}/ergebnis	ja	Erfasst das Abstimmungsergebnis EINES Beschluss-TOP: --ergebnis angenommen \	abgelehnt (Pflicht, die Feststellung; sie wird nie aus den Zahlen abgeleitet), --ja/--nein/--enthaltung (Köpfe) und --anteile-ja/--anteile-nein/--anteile-enthaltung (Zehntausendstel), je eine ganze Zahl >= 0; nicht genannte Zahlen werden leer gespeichert. Erneutes Setzen überschreibt, solange die Versammlung nicht abgeschlossen ist. Geschäftsordnungs- und Notiz-TOPs haben keine Abstimmung (top-ohne-abstimmung). Ein offensichtlicher Widerspruch (angenommen bei mehr Nein- als Ja-Stimmen) steht als Hinweis ergebnis-widerspricht-zahlen in der Antwort, nie als Fehler.
versammlung verkuenden <id>	POST	/api/versammlung/{id}/verkuendung	ja	Verkündet die Versammlung: --am <JJJJ-MM-TT> (Pflicht, nicht vor dem Versammlungsdatum, nicht in der Zukunft). Setzt das Verkündungsdatum EINMAL (zweites Verkünden ⇒ bereits-verkuendet). Voraussetzung: Status durchgefuehrt, mindestens ein Beschluss-TOP, jeder Beschluss-TOP hat ein Ergebnis. Die Antwort zeigt anfechtungsfristEnde (ein Monat ab Verkündung, § 45 WEG), das rechnerische Ende und den Hinweis, dass Feiertage nicht berücksichtigt sind.
versammlung beschluesse-generieren <id>	POST	/api/versammlung/{id}/beschluesse	ja	Übernimmt die verkündeten Beschlüsse der Versammlung in die Beschluss-Sammlung des Objekts (laufende Nummer = größte des Objekts + 1, fortlaufend; TOP-Reihenfolge). Voraussetzung: die Versammlung ist verkündet (versammlung verkuenden), hat mindestens einen Beschluss-TOP und jeder Beschluss-TOP hat ein Ergebnis. Genau EINMAL: danach ist die Versammlung abgeschlossen und unveränderlich, eine zweite Übernahme ⇒ bereits-generiert. Alles oder nichts. Geschäftsordnungs- und Notiz-TOPs werden nicht übernommen; sie stehen als übersprungen in der Antwort. Body: --data '{}'.
versammlung umlauf eroeffnen <id>	POST	/api/versammlung/{id}/umlauf	ja	Eröffnet den Umlaufbeschluss einer Versammlung der Art umlauf (Status entwurf, genau ein Beschluss-TOP): --frist <JJJJ-MM-TT> (Pflicht, Ende der Antwortfrist), --mehrheitsregel allstimmig (Default) \	mehrheit_abgegebene, --absenkung-beschluss <beschlussId> (Pflicht bei mehrheit_abgegebene); Stimmgewichte je Person per --data (stimmgewichte: [{personId, stimmgewicht}], Pflicht bei Stimmprinzip mea und objekt). Legt je Eigentümer-Person eine Rücklaufzeile an. Allstimmigkeit ist der Default (alle Eigentümer in Textform, § 23 Abs. 3 S. 1 WEG); die abgesenkte Mehrheit (--mehrheitsregel mehrheit_abgegebene) braucht einen vorher gefassten Beschluss (--absenkung-beschluss), und das System prüft nicht, ob er sich auf diesen Gegenstand bezieht. Die Frist ist keine Ausschlussfrist: Antworten bis zur Feststellung zählen. Ohne Verkündung gibt es keinen Beschluss in der Sammlung; ein nicht zustande gekommener Umlauf geht als „abgelehnt“ in die Sammlung.
versammlung umlauf ruecklauf <id>	POST	/api/versammlung/{id}/umlauf/ruecklauf	ja	Erfasst die Antwort EINER Person: --person <personId> (Eigentümer auf der Rücklaufliste), --antwort ja \	nein \	enthaltung, --am <JJJJ-MM-TT> (Eingangsdatum, nicht vor der Eröffnung, nicht in der Zukunft), --kanal portal \	email \	post \	sonstiges (alle Pflicht), --textform (Schalter: die Textform ist bestätigt; eine Zustimmung gilt nur in Textform), --notiz <text>. Eine spätere Antwort überschreibt die frühere, solange nicht festgestellt ist. Antworten nach dem Fristende zählen (Hinweis nach-fristablauf); die Antwort zeigt den Zählstand. Die Frist ist keine Ausschlussfrist: Antworten bis zur Feststellung zählen.
versammlung umlauf stand <id>	GET	/api/versammlung/{id}/umlauf	ja	Liest den Stand des Umlaufs: Vorgang (Mehrheitsregel, Frist, Feststellung, Mitteilung), Rücklaufliste mit Namen und Stimmgewichten (Integer-Strings), Zählung, fristAbgelaufen und feststellbar (wahr: casa versammlung umlauf feststellen gelingt jetzt). Bis zur Feststellung zählt der Server live mit dem heutigen Tag, danach gilt die eingefrorene Zählung. Allstimmigkeit ist der Default; die abgesenkte Mehrheit rechnet über die abgegebenen Stimmen.
versammlung umlauf feststellen <id>	POST	/api/versammlung/{id}/umlauf/feststellung	ja	Stellt das Ergebnis des Umlaufs fest (einmalig): friert die Zählung ein und schreibt das Ergebnis in den Beschluss-TOP. Möglich, sobald alle geantwortet haben (Allstimmigkeit: auch bei einem Nein) oder das Fristende vorbei ist (feststellbar im Stand); sonst Konflikt, nichts geschrieben. Ein zweiter Aufruf ⇒ Konflikt umlauf-festgestellt. Kein Body nötig. Ein nicht zustande gekommener Umlauf geht als „abgelehnt“ in die Sammlung.
versammlung umlauf verkuenden <id>	POST	/api/versammlung/{id}/umlauf/verkuendung	ja	Verkündet den festgestellten Umlauf (einmalig): --am <JJJJ-MM-TT> (Verkündungsdatum, nicht vor dem Versammlungsdatum, nicht in der Zukunft) und --form textform \	brief (Form der Mitteilung an die Eigentümer) sind Pflicht. Die Antwort zeigt anfechtungsfristEnde (ein Monat ab Verkündung, § 45 WEG). Auch ein nicht zustande gekommener Umlauf wird verkündet; danach übernimmt casa versammlung beschluesse-generieren das Ergebnis in die Sammlung; ohne Verkündung gibt es keinen Beschluss in der Sammlung.
objekt brennstoffkonto show <id>	GET	/api/objekt/{id}/brennstoffkonto	ja	Liest das Brennstoffkonto eines Objekts: <objektId>. Zeigt das aktive Konto (Kontonummer, Name, Zustand, gesetztAm), den gemerkten Ausgangszustand (vorzustand), den Befund (brennstoffkonto-verteilt-doppelt, wenn das Brennstoffkonto trotzdem umlagefähig ist oder einen Umlageschlüssel trägt) und die Konten des Objekts mit Heizkosten-Kostenart (heizkostenKonten) als Auswahlhilfe für setzen. Das Brennstoffkonto verteilt die Heizkosten über die Heizkostenabrechnung und darf nicht zusätzlich als Betriebskosten umgelegt werden (sonst stehen die Heizkosten doppelt in der Abrechnung). Nur lesend.
objekt brennstoffkonto setzen <id>	POST	/api/objekt/{id}/brennstoffkonto	ja	Setzt oder wechselt das Brennstoffkonto eines Objekts: <objektId> --konto <glAccountId> (Pflicht; Auswahlhilfe: casa objekt brennstoffkonto show) und --bestaetigt (Schalter ohne Wert). Das Brennstoffkonto verteilt die Heizkosten über die Heizkostenabrechnung und darf nicht zusätzlich als Betriebskosten umgelegt werden (sonst stehen die Heizkosten doppelt in der Abrechnung). Setzen macht das Konto nicht umlagefähig und entfernt den Umlageschlüssel, deshalb ist --bestaetigt immer Pflicht (ohne die Flagge fehlt bestaetigt im Body: 400 mit Klartext, was verloren geht, nichts geschrieben; --bestaetigt=false ist erlaubt und bestätigt nicht, ein umlagefähiges Konto wird dann abgelehnt). Das frühere Brennstoffkonto geht auf seinen gespeicherten Ausgangszustand zurück. Ein Konto mit Buchungen wird nicht umgestellt (409 konto-gebucht); dasselbe Konto zweimal ⇒ 409 bereits-brennstoffkonto. Ein Agent darf nicht (403). Mit --idempotency-key wiederholungssicher.
objekt brennstoffkonto aufheben <id>	POST	/api/objekt/{id}/brennstoffkonto/aufheben	ja	Hebt das Brennstoffkonto eines Objekts auf: <objektId> und --bestaetigt (Schalter ohne Wert). Die Markierung endet, das Konto geht auf seinen gespeicherten Ausgangszustand zurück. --bestaetigt ist immer Pflicht (ohne die Flagge fehlt bestaetigt im Body: 400 mit Klartext, nichts geschrieben; wird das Konto dadurch wieder umlagefähig oder erhält es einen Umlageschlüssel, laufen seine Kosten wieder in die Betriebskostenumlage). Ein inzwischen gebuchtes Konto bleibt wie es ist (Hinweis in der Antwort). Hat das Objekt kein Brennstoffkonto ⇒ 404. Ein Agent darf nicht (403).
objekt abschluss list <id>	GET	/api/objekt/{id}/abschluss	ja	Liest die Abschluss-Läufe eines Objekts. --jahr <wirtschaftsjahr> filtert; ein Jahr ohne Lauf ergibt eine LEERE Liste, keinen Fehler. Stornierte Läufe verschwinden NICHT aus dem Bestand (GoBD) — sie tragen storniert: true.
abschluss freeze <id>	GET	/api/abschluss/{id}/freeze	ja	Fragt, ob an einer Abrechnung noch geschrieben werden darf. --vorhaben storno\	neuberechnung ist Pflicht. Ein bestandskräftiger Lauf + neuberechnung endet NICHT mit 0 und nennt den Korrekturweg — ein stilles „nichts passiert" sähe für den Bediener wie Erfolg aus.
abschluss storno <id>	POST	/api/abschluss/{id}/storno	ja	Storniert EINEN Abschluss-Lauf. --grund und --stichtag sind Pflicht: ein Storno ohne Begründung ist im Audit wertlos, und der Tag darf nicht aus der Uhr des Servers kommen (BP §8). Ein zweites Storno desselben Laufs wird abgewiesen.
objekt abschluss korrektur <id>	POST	/api/objekt/{id}/abschluss/korrektur	ja	Führt die Korrektur-Kette einer Kaskaden-Neuberechnung aus: je betroffenem Jahr ein Storno und ein NEUER Lauf mit Referenz auf den stornierten. --data '{"jahr":2024,"schluessel":"weg-abschluss-korrektur\	…"}'. Der Idempotenz-Schlüssel kommt vom Aufrufer — zwei Aufrufe am selben Schlüssel ergeben GENAU EINEN neuen Lauf.
datev buchungsstapel	POST	/api/datev/buchungsstapel	ja	Erzeugt den DATEV-Buchungsstapel (EXTF 700) für ein oder mehrere Objekte und ein Kalenderjahr und schreibt die Datei nach --out <pfad> (Windows-1252, byte-genau; vorhandenes Ziel nur mit --ueberschreiben). Der Lauf steht danach in der Export-Historie. Pflicht: --objekte <uuid[,uuid…]> ("alle" ist eine Wahl, kein Vorgabewert), --jahr JJJJ (Kalenderjahr; Zeitraum 01.01. bis 31.12., mit abweichendem --wirtschaftsjahr-beginn nur der Teil des Jahres, der in diesem Wirtschaftsjahr liegt), --beraternummer (1-7 Ziffern), --mandantennummer (1-5 Ziffern), --sachkontenlaenge 4-8, --kontenrahmen skr03\	skr04, --festschreibung 0\	1, --out. Optional: --wirtschaftsjahr-beginn JJJJ-MM-TT (Vorgabe: 01.01. des Jahres). --festschreibung ist das Festschreibekennzeichen im Kopfsatz (GoBD-Angabe an DATEV): 1 = die Daten gelten bei DATEV als festgeschrieben, 0 = nicht; es gibt keinen Vorgabewert. Der Export löst KEINE Festschreibung in casa.ai aus. Das Ergebnis nennt Anzahl (buchungszeilen, buchungssaetze), summeCents, dateiname, sha256 und laufId; ist der Zeitraum nicht durch festgeschriebene Perioden gedeckt, steht der Hinweis dazu in "hinweise" (Hinweis, kein Abweis; die Datei wird trotzdem geschrieben). Abweichendes Wirtschaftsjahr: zwei Stapel, also zwei Läufe für zwei Kalenderjahre (--jahr 2024 ⇒ 01.07.–31.12.2024, --jahr 2025 ⇒ 01.01.–30.06.2025; berührt das Wirtschaftsjahr das Jahr nicht ⇒ 400), z. B. casa datev buchungsstapel --objekte <uuid> --jahr 2024 --wirtschaftsjahr-beginn 2024-07-01 --out a.csv … und danach --jahr 2025 --wirtschaftsjahr-beginn 2024-07-01 --out b.csv …. Leerer Umfang, fehlende Kontenzuordnung, falsche Sachkontenlänge ⇒ 409 mit Klartext, keine Datei; fremdes oder nicht zuständiges Objekt ⇒ 404. Wiederholungssicher mit --idempotency-key.
datev historie	GET	/api/datev/historie	ja	Listet die früheren DATEV-Buchungsstapel-Läufe, jüngster zuerst: laufId, Zeitraum (zeitraumVon/zeitraumBis), objekte, dateiname, sha256, buchungszeilen, summeCents, erzeugtAm und erzeugende Person; nie Buchungstexte und keine Datei-Bytes. Optional --objekt <uuid> (mehrere kommagetrennt) grenzt auf Läufe ein, die eines dieser Objekte berühren, --limit <1..200> bestimmt die Seitengröße, --weiter <cursor> holt die nächste Seite (der Wert "weiter" der vorigen Antwort; null = Historie zu Ende). Gezeigt werden Läufe über die Objekte, für die Sie zuständig sind; ein Lauf über mehrere Objekte steht (nur als Kennzahlen) in der Liste jedes seiner Objekte. Die Historie hält nur die Stapel-Datei: ein Belegpaket (ZIP) und die DebKred-Datei sind nicht darin. Die Datei eines Laufs holt "datev herunterladen <laufId> --out <pfad>". Lesen erzeugt keinen Lauf und keinen Eintrag.
datev herunterladen <laufId>	GET	/api/datev/historie/{laufId}/datei	ja	Lädt die Stapel-Datei eines früheren Laufs (Positional <laufId> aus "datev historie") erneut nach --out <pfad>: byte-gleich zum ursprünglichen Export (gleiche sha256), ohne neuen Buchungslauf, ohne neuen Kommando-Log-Eintrag und ohne neue Historien-Zeile; ein vorhandenes Ziel nur mit --ueberschreiben. Nur die Stapel-Datei liegt in der Historie: ein Belegpaket (ZIP) und die DebKred-Datei sind nicht darin und nicht erneut holbar. Unbekannte, fremde oder nicht vollständig zuständige laufId (ein Lauf über Objekte, für die Sie nicht alle zuständig sind) ⇒ 404 (not_found), keine Datei. Passen die abgelegten Bytes nicht mehr zu ihrer sha256, gibt es einen Serverfehler und keine Datei.
datev belegpaket	POST	/api/datev/belegpaket	ja	Erzeugt den DATEV-Buchungsstapel MIT Beleglinks und das zugehörige Belegpaket (ZIP mit document.xml und den unveränderten Original-Belegen) in einem Lauf und schreibt zwei Dateien: den Stapel nach --out <pfad> (Windows-1252) und das ZIP nach --belegpaket-out <pfad>; beide byte-genau, vorhandene Ziele nur mit --ueberschreiben. Dieselben Pflicht-Flags wie "datev buchungsstapel" (--objekte, --jahr, --beraternummer, --mandantennummer, --sachkontenlaenge, --kontenrahmen, --festschreibung; optional --wirtschaftsjahr-beginn) plus beide Ziele. --belegpaket-out ist Pflicht, weil die CLI vor dem Aufruf nicht wissen kann, ob Belege existieren; fehlt es, gibt es einen Bedienfehler und keinen Netzaufruf. Hat keine Buchung einen übertragbaren Beleg, gibt es kein ZIP: "belegpaket" ist dann null, --belegpaket-out wird nicht geschrieben und "hinweis" nennt den Grund; der Stapel wird trotzdem geschrieben. "ohneBeleg" listet die Buchungszeilen ohne Beleg im Paket (zeilenNr und grund, nie Buchungstext oder Namen); eine Buchung mit Hash-Abweichung des Originals gilt als nicht übertragbar (original_beschaedigt). Der Lauf ist derselbe wie bei "datev buchungsstapel" (eine Historien-Zeile): in der Export-Historie liegt danach nur die Stapel-Datei mit den Beleglinks; das ZIP wird NICHT abgelegt und ist nur in dieser Antwort holbar (siehe "hinweise" in "stapel"), also jetzt sichern. Die Festschreibung löst der Export nicht aus (--festschreibung ist nur das Kennzeichen im Kopfsatz). Leerer Umfang, fehlende Kontenzuordnung, falsche Sachkontenlänge ⇒ 409 mit Klartext, keine Datei; fremdes oder nicht zuständiges Objekt ⇒ 404; Belegspeicher nicht erreichbar ⇒ 503, nichts exportiert und keine Historien-Zeile. KEIN Replay: ein zweiter Aufruf mit demselben --idempotency-key liefert das ZIP nicht erneut (es wird nicht abgelegt, und der Zeitstempel im Stapel ist je Aufruf ein anderer), sondern endet mit 409 conflict; die Historie behält genau eine Zeile. Für eine erneute Datei einen neuen Schlüssel verwenden.
datev debkred	POST	/api/datev/debkred	ja	Erzeugt die DATEV-Stammdatendatei Debitoren/Kreditoren (EXTF, Personenkonten mit Name, Anschrift und bestätigter IBAN) zu einem Buchungsstapel und schreibt sie nach --out <pfad> (Windows-1252, byte-genau; vorhandenes Ziel nur mit --ueberschreiben). Dieselben Pflicht-Flags wie "datev buchungsstapel" (--objekte, --jahr, --beraternummer, --mandantennummer, --sachkontenlaenge, --kontenrahmen, --festschreibung, --out; optional --wirtschaftsjahr-beginn) plus --umfang buchungsstapel\	alle-aktiven (Pflicht, kein Vorgabewert): "buchungsstapel" = genau die Personenkonten des Stapels desselben Zeitraums, "alle-aktiven" = zusätzlich jedes nicht archivierte Personenkonto der Objekte und alle Kreditoren. Das Ergebnis nennt dateiname, sha256, personenkonten und mitBankverbindung (Zahlen, keine IBAN). ACHTUNG: Die Datei enthält Namen, Anschriften und IBANs. Sie wird NICHT in der Export-Historie abgelegt und ist nicht erneut abrufbar (Hinweis in "hinweise": nicht in der Historie abgelegt, Datei jetzt sichern); der Beleg im Kommando-Log trägt nur sha256 und Zahlen. Leerer Umfang, fehlende Kontenzuordnung, falsche Sachkontenlänge, Personenkonto ohne Geschäftspartner ⇒ 409 mit Klartext (ohne Namen), keine Datei; fremdes oder nicht zuständiges Objekt ⇒ 404. Wiederholungssicher mit --idempotency-key: ein Retry mit gleichem Key, gleichen Flags und unveränderten Stammdaten liefert dieselbe Datei erneut (ohne Ablage); anderer Body oder geänderte Stammdaten unter demselben Key ⇒ 409, keine Datei.
objekt buchungsperioden <id>	GET	/api/objekt/{id}/buchungsperioden	ja	Zeigt Stand und Protokoll der festschreibbaren Buchungsperioden eines Objekts: "aktiv" (Schalter des Objekts, sonst Vorgabe des Mandanten, sonst aus), "wirtschaftsjahrBeginn" ("kalenderjahr" oder "abweichend_MM-DD"), je Festschreibung "von"/"bis" und Status "geltend" (gesperrt) oder "geoeffnet" (mit Grund, wer, wann) und im "protokoll" je Öffnung die Journalsätze, die zwischen Öffnung und Neu-Festschreiben mit Datum in der Periode gebucht wurden (Storno- und Ergänzungsbuchungen; offene Posten und Sollstellungen stehen nicht darin). Bei ausgeschaltetem Schalter bleibt eine festgeschriebene Periode gesperrt und steht als "geltend" da. --format export liefert dieselben Daten als deterministische Export-Datei (gleiche Daten ergeben gleiche Bytes, ohne Erzeugungszeit; Ersatz für das PDF zur Vorlage bei den Finanzbehörden). ACHTUNG: der Öffnungsgrund ist Freitext (personenbezogen möglich). Unbekanntes, fremdes oder nicht zuständiges Objekt ⇒ 404.
objekt festschreiben <id>	POST	/api/objekt/{id}/buchungsperioden/festschreibung	ja	Schreibt die nächste Buchungsperiode eines Objekts fest (Wirtschaftsjahr des Objekts, lückenlos) oder schreibt eine geöffnete Periode neu fest. Braucht --data '{}'; bei der ERSTEN Festschreibung --data '{"von":"2025-01-01"}' (Beginn eines Wirtschaftsjahres), bei einer geöffneten Periode ihr Beginn als "von". Nur ein Mensch; der Schalter des Objekts muss an sein ("einstellungen festschreibung"). Gesperrt, Lücke, kein Jahresbeginn, Wirtschaftsjahr unklar ⇒ 409 mit Code (PERIODE_FESTGESCHRIEBEN, FESTSCHREIBUNG_LUECKE, FESTSCHREIBUNG_KEIN_JAHRESBEGINN, WIRTSCHAFTSJAHR_UNKLAR); fremdes Objekt ⇒ 404; Agent ⇒ 403. Wiederholungssicher mit --idempotency-key.
objekt oeffnen <id>	POST	/api/objekt/{id}/buchungsperioden/oeffnung	ja	Öffnet eine festgeschriebene Buchungsperiode eines Objekts mit Pflichtgrund (auch eine mittlere): --data '{"festschreibungId":"<uuid>","grund":"Nachtrag Beleg"}' (die Id steht in "objekt buchungsperioden"). Der Grund ist Pflicht (nicht leer) und wird mit Person und Zeitpunkt unveränderlich protokolliert; er ist Freitext (personenbezogen möglich). Danach sind Storno- und Ergänzungsbuchungen mit Datum in der Periode möglich, bis sie neu festgeschrieben wird ("objekt festschreiben"). Schon geöffnet ⇒ 409; fremd oder nicht zum Objekt gehörig ⇒ 404; Agent ⇒ 403. Wiederholungssicher mit --idempotency-key.
einstellungen festschreibung	POST	/api/einstellungen/festschreibung	ja	Schaltet die Festschreibung der Buchungsperioden ein oder aus: --data '{"propertyId":"<uuid>","aktiv":true}' für ein Objekt, "propertyId": null für die Vorgabe des Mandanten (Vorgabe ist aus). Ausschalten lässt bereits festgeschriebene Perioden gesperrt. Nur ein Mensch mit Admin-Recht (sonst 403); fremdes oder unbekanntes Objekt ⇒ 404. Wiederholungssicher mit --idempotency-key.
auswertung einnahmen-ausgaben	GET	/api/auswertung/einnahmen-ausgaben	ja	Liest das Einnahmen-/Ausgaben-Journal eines Objekts für einen Zeitraum — je Geldbewegung eine Zeile mit Gegenkonto, Beleg und Netto/USt/Brutto, dazu die Summen je Gegenkonto. PFLICHT: --objekt <objektId> --von <YYYY-MM-DD> --bis <YYYY-MM-DD>. --je-konto <kontonummer> grenzt auf EIN Gegenkonto ein. Alle Cent-Felder sind Integer-STRINGS. Eine Umbuchung zwischen zwei Geldkonten ist weder Einnahme noch Ausgabe — sie steht in "umbuchungen"; "ohneGeldkontoSeite" zählt die Sätze des Zeitraums ohne Geldkonto-Zeile (Sollstellungen). Ein Bestandsvortrag (entry_type eroeffnung) ist KEINE Einnahme — das Geld war schon da; er steht in "eroeffnungen". "ustHerkunft" sagt je Zeile, ob die USt GEBUCHT oder aus dem Satz ABGELEITET ist. "verrechnet": true kennzeichnet eine Zeile, die innerhalb ihres Satzes gegen die Geldkonto-Seite verrechnet wurde (Einbehalt, Abzug) — sie zählt voll als Einnahme bzw. Ausgabe, und "geldkonten" nennt das Konto, gegen das verrechnet wurde. Unbekanntes oder fremdes Objekt ⇒ error.code "not_found" bei Exit 5 (kein Existenz-Orakel).
auswertung einnahmen-ueberschuss	GET	/api/auswertung/einnahmen-ueberschuss	ja	Einnahmen-Überschuss-Aufstellung EINES Objekts für EIN Kalenderjahr (Zufluss/Abfluss, § 11 EStG): Einnahmen und Werbungskosten je Gruppe (Miete, Umlagen, umlagefähige Kosten, Instandhaltung, Verwaltung, Sonstige), Brutto/USt/Netto und Überschuss. Pflicht: --objekt <uuid> --jahr JJJJ. Optional --eigentuemer <personId> (sein Anteil nach Eigentumsanteil, Rest-Cent nach größtem Rest; fehlt ⇒ Objekt gesamt) und --format csv (Ausgabe ist dann die CSV-Datei auf stdout — für Eigentümer oder Steuerberater). Kautionen, durchlaufende Posten, Rücklagen und Einlagen/Entnahmen des Eigentümers zählen nicht. Betrags-Zellen sind Integer-Cent-STRINGS. Unbekanntes/fremdes Objekt oder Person ohne Anteil ⇒ not_found (Exit 5); Einheit ohne Eigentümer oder uneinheitliche Anteile ⇒ invalid_request (HTTP 422).
objekt vermoegensbericht list <id>	GET	/api/objekt/{id}/vermoegensbericht	ja	Liest die abgelegten Vermögensberichts-Stände eines Objekts (§ 28 Abs. 4 WEG). --stichtag <YYYY-MM-DD> filtert; ein Objekt ohne Stand ergibt eine LEERE Liste, keinen Fehler. Ältere Stände verschwinden NICHT (GoBD) — sie tragen ihre standNr, der jüngste zuerst.
objekt vermoegensbericht erstellen <id>	POST	/api/objekt/{id}/vermoegensbericht	ja	Erzeugt den Vermögensbericht eines Objekts zum Stichtag und legt ihn als NEUEN Stand ab. --data '{"stichtag":"2024-12-31","schluessel":"vermoegensbericht\	…","auftrag":{…}}'. Der Idempotenz-Schlüssel kommt vom Aufrufer: zwei Aufrufe am selben Schlüssel ergeben GENAU EINEN Stand. Readiness- und Konsistenz-Befunde stehen in der Antwort — sie gehören zum Bericht.
vermoegensbericht zeigen <id>	GET	/api/vermoegensbericht/{id}	ja	Liest EINEN abgelegten Stand samt seiner Readiness- und Konsistenz-Befunde. --onr <objektId> ist Pflicht: der Stand ist an BEIDEN Achsen verankert, und ein Stand der Nachbargemeinschaft ist über diesen Weg nicht lesbar.
migration vergleich <id>	GET	/api/migration/{id}/vergleich	ja	Liest den centgenauen Abweichungsbericht je Fachbereich zu einem Import-Vorgang: casa.ai rechnet den importierten Bestand nach und stellt ihn gegen die WinCASA-Vergleichswerte des jüngsten Satzes. Cent-Beträge stehen als Ganzzahl-Text. Ein fremder und ein unbekannter Vorgang sehen gleich aus (nicht gefunden).
objekt hausgeld list <id>	GET	/api/objekt/{id}/hausgeld	ja	Liest die Hausgeld-Sollstellungen eines Objekts (§ 28 Abs. 1 WEG). --jahr <wirtschaftsjahr> filtert; ein Jahr ohne Soll ergibt eine LEERE Liste, keinen Fehler. Vorschuss und rückwirkende Differenz stehen NEBENEINANDER — die Differenz ersetzt den Vorschuss nicht.
objekt hausgeld soll <id>	POST	/api/objekt/{id}/hausgeld/soll	ja	Stellt das Hausgeld eines Objekts für ein Wirtschaftsjahr fällig — je Einheit und Monat eine Sollstellung. --data '{"jahr":2024,"geldkreis":"weg_hausgeld","schluessel":"hausgeld-soll\	…",…}'. Der Idempotenz-Schlüssel kommt vom Aufrufer: zwei Läufe am selben Schlüssel stellen GENAU EINMAL Soll. Rückwirkende Differenzen liefert der Lauf als VORSCHLAG und bucht sie nicht.
objekt hausgeld differenz <id>	POST	/api/objekt/{id}/hausgeld/differenz	ja	Quittiert rückwirkende Differenz-Vorschläge eines Soll-Laufs — der GEFÜHRTE Schritt. --von und --am sind Pflicht: ein anonymer Freigabeschritt ist keiner (GoBD), und der Tag kommt nicht aus der Uhr des Servers (BP §8). Die Vorschläge reisen so, wie der Lauf sie geliefert hat — Schuldner und Plan-Version werden nicht neu abgeleitet.
objekt ruecklage list <id>	GET	/api/objekt/{id}/ruecklagen	ja	Listet den Katalog der Rücklagen eines Objekts (älteste zuerst) mit Art, Bezeichnung, Zweckbindung, Konten, Kontoinhaber, Ist-Bestand und Kennzeichen "aufgeloest". --stichtag <YYYY-MM-DD> nennt den Tag des Ist-Bestands (inklusive); ohne ihn ist der Ist-Bestand null. Aufgelöste Rücklagen bleiben im Katalog. Geld ist ein Objekt {cents, currency}.
objekt ruecklage soll-ist <id>	GET	/api/objekt/{id}/ruecklagen/soll-ist	ja	Liest Soll, Ist und Rückstand der Rücklagen eines Objekts zum Stichtag. Pflicht: --stichtag <YYYY-MM-DD> (inklusive). --ruecklageId <uuid> beschränkt auf eine Rücklage; ohne sie kommen alle Rücklagen des Objekts. Eine fremde oder unbekannte Rücklage ist not_found. Geld ist ein Objekt {cents, currency}.
objekt ruecklage abstimmung <id>	GET	/api/objekt/{id}/ruecklagen/abstimmung	ja	Stimmt das aktive Bestandskonto gegen das passive Rücklagenkonto ab, je Rücklage und gesamt, mit Befunden (fehlende Umbuchung Giro → Festgeld, Konto ohne Gegenstück). Pflicht: --stichtag <YYYY-MM-DD> (inklusive). Ein Konto, das mehrfach im Katalog steht, ist ein Konflikt. Geld ist ein Objekt {cents, currency}.
objekt ruecklage wiedervorlagen <id>	GET	/api/objekt/{id}/ruecklagen/wiedervorlagen	ja	Listet die offenen Zwischenfinanzierungen eines Objekts (noch nicht zurückgeführt) mit Fälligkeit, Frist, Betrag und Beschluss-Referenz, nach Fälligkeit geordnet. Pflicht: --bis <YYYY-MM-DD>: überfällig ist, was VOR diesem Tag fällig war (eine Auskunft, keine Sperre). Geld ist ein Objekt {cents, currency}.
objekt ruecklage anlegen <id>	POST	/api/objekt/{id}/ruecklagen	ja	Legt eine Rücklage des Objekts samt Kontenpaar an (passives Rücklagenkonto, aktives Bestandskonto). --art erhaltung\	zweckgebunden, --bezeichnung, --kontoinhaberArt gdwe\	verwalter\	dritter, --kontoinhaberName sind Pflicht; --zweckbindung ist bei zweckgebunden Pflicht und bei erhaltung verboten; optional --verteilerschluessel, --unitGroupId, --aktivKontoId (ein bestehendes Bankkonto des Objekts). Die Erhaltungsrücklage gibt es je Objekt genau einmal.
objekt ruecklage soll <id>	POST	/api/objekt/{id}/ruecklagen/soll	ja	Legt die Soll-Zuführung einer Rücklage fest, gebunden an einen Beschluss-Teilgegenstand. Pflicht: --ruecklageId <uuid>, --betrag <Cent als Ziffern-String, > 0, z. B. 120000 = 1.200,00 €>, --beschluss <beschluss-gegenstand:uuid>, --datum <YYYY-MM-DD> (Fälligkeit). Ohne Beschluss-Referenz wird nichts gespeichert.
objekt ruecklage buchen <id>	POST	/api/objekt/{id}/ruecklagen/buchung	ja	Bucht eine Bewegung auf dem passiven Rücklagenkonto. --betrag ist ein vorzeichenbehafteter Ziffern-String in CENT: 5000 = Zuführung von 50,00 €, --betrag -5000 = Entnahme von 50,00 €. Pflicht: --ruecklageId, --betrag, --datum <YYYY-MM-DD>, --gegenkonto <uuid>. Zuführung: optional --periode <YYYY-MM>, dieselbe Periode wird nur EINMAL gebucht (zweite Antwort ausgang bereits_gebucht, kein zweiter Journalsatz). Entnahme: --zweck wartung\	inspektion\	instandsetzung\	modernisierende_instandsetzung\	bauliche_veraenderung\	modernisierung ist Pflicht; bauliche_veraenderung und modernisierung brauchen --umwidmung <Umwidmungsbeschluss-Referenz>; optional --beschluss. Korrektur: Gegenbewegung mit umgekehrtem Vorzeichen und --korrigiert <bewegungId>.
objekt ruecklage zins <id>	POST	/api/objekt/{id}/ruecklagen/zins	ja	Erfasst einen Zinsertrag einer Rücklage: brutto wird in Kapitalertragsteuer (25 %), Solidaritätszuschlag (5,5 % auf die Steuer) und netto aufgeteilt. Pflicht: --ruecklageId, --brutto <Cent als Ziffern-String, > 0>, --datum <YYYY-MM-DD>, --zinskonto <uuid>, --steuerkonto <uuid>. Ein negativer Zins (Verwahrentgelt) hat hier keinen Weg.
objekt ruecklage zwischenfinanzierung <id>	POST	/api/objekt/{id}/ruecklagen/zwischenfinanzierung	ja	Entnimmt der Rücklage kurzfristig Liquidität gegen Beschluss und legt eine Wiedervorlage an. Pflicht: --ruecklageId, --betrag <Cent als POSITIVER Ziffern-String>, --datum <YYYY-MM-DD>, --beschluss <Beschluss-Referenz>. Optional --frist <Monate> (überschreibt die Policy-Frist, Vorgabe 3) und --gegenkonto <uuid> (sonst das Bestandskonto der Rücklage). Die Rückführung ist ein eigenes Kommando.
objekt ruecklage rueckfuehrung <id>	POST	/api/objekt/{id}/ruecklagen/rueckfuehrung	ja	Führt eine Zwischenfinanzierung in voller Höhe in die Rücklage zurück. Pflicht: --ruecklageId, --zwischenfinanzierung <bewegungId der Entnahme>, --datum <YYYY-MM-DD>, --gegenkonto <uuid>. Offene Zwischenfinanzierungen zeigt casa objekt ruecklage wiedervorlagen.
objekt ruecklage aufloesen <id>	POST	/api/objekt/{id}/ruecklagen/aufloesung	ja	Löst eine Rücklage auf — nur gegen Aufhebungsbeschluss und nur bei Saldo 0,00 €. Pflicht: --ruecklageId, --beschluss <Aufhebungsbeschluss-Referenz>, --datum <YYYY-MM-DD>. Die Rücklage bleibt im Katalog (aufgeloest true), danach wird nichts mehr auf sie gebucht.
objekt sonderumlage list <id>	GET	/api/objekt/{id}/sonderumlage	ja	Listet die Sonderumlagen eines Objekts (nach Fälligkeit) mit Zweck, Gesamtbetrag, Zahlweise, Raten-Fälligkeiten, Kennzeichen "gestellt" (Soll steht) und der Tatsache "schluesselAbweichung". Geld ist ein Objekt {cents, currency}.
objekt sonderumlage show <id>	GET	/api/objekt/{id}/sonderumlage/soll	ja	Zeigt das gestellte Soll EINER Sonderumlage je Einheit und Rate mit Schuldnern (Eigentümer am Fälligkeitstag, Anteil in Zehntausendsteln). Pflicht: --sonderumlageId <uuid>. Solange das Soll nicht gestellt ist, ist die Einheitenliste leer. Eine fremde oder unbekannte Sonderumlage ist not_found.
objekt sonderumlage anlegen <id>	POST	/api/objekt/{id}/sonderumlage	ja	Legt eine Sonderumlage mit ihrem Sonderkonto an, gebunden an einen Beschluss-Teilgegenstand. Pflicht: --beschluss <beschluss-gegenstand:uuid>, --zweck <Text laut Beschluss>, --betrag <Gesamtbetrag in Cent als Ziffern-String, > 0, z. B. 1200000 = 12.000,00 €>, --faelligkeit <YYYY-MM-DD>, --zahlweise einmalzahlung\	raten. Bei raten zusätzlich --raten <YYYY-MM-DD,YYYY-MM-DD,…> (die erste Rate ist die Fälligkeit); bei einmalzahlung keine Raten. Optional --zufuehrungsSchluessel (Vorgabe mea), --entnahmeSchluessel, --abweichungsBeschluss. Ohne Beschluss, Zweck oder Fälligkeit wird nichts gespeichert.
objekt sonderumlage soll <id>	POST	/api/objekt/{id}/sonderumlage/soll	ja	Stellt eine Sonderumlage Soll: Verteilung nach Miteigentumsanteil auf die Einheiten, Teilung in Raten, Schuldner je Rate ist der Eigentümer am Fälligkeitstag. Pflicht: --sonderumlageId <uuid>. Optional --laufTyp sonderzufuehrung (Vorgabe) und --abweichungsBeschluss. Append-only: ein zweiter Aufruf stellt nichts neu und antwortet mit ausgang bereits_ausgefuehrt (Erfolg, Exit 0). Das gestellte Soll zeigt casa objekt sonderumlage show.
objekt wirtschaftsplan list <id>	GET	/api/objekt/{id}/wirtschaftsplan	ja	Listet die Versionen der Wirtschaftspläne eines Objekts (Jahr und Version aufsteigend, mit Status und Jahres-Soll). --jahr <wirtschaftsjahr> filtert; ein Jahr ohne Plan ergibt eine LEERE Liste, keinen Fehler. Geld ist ein Objekt {cents, currency}.
objekt wirtschaftsplan show <id>	GET	/api/objekt/{id}/wirtschaftsplan/stand	ja	Liest EINE Version eines Wirtschaftsplans: --jahr <wirtschaftsjahr> --version <n> (beide Pflicht). --vergleichMit <n> liefert zusätzlich den Diff von --version zur genannten Version; --berechnung true liefert Gesamtplan, Einzelpläne mit Monatsbeträgen und Befunde (serverseitig gerechnet). Geld ist ein Objekt {cents, currency}.
objekt wirtschaftsplan anlegen <id>	POST	/api/objekt/{id}/wirtschaftsplan	ja	Legt den Wirtschaftsplan eines Objekts für ein Wirtschaftsjahr als Version 1 (Status entwurf) an. --data '{"jahr":2027,"positionen":[{"kostenart":"Hausmeister","art":"kosten","betrag":{"cents":"1200000","currency":"EUR"},"verteilerschluessel":"mea"},{"kostenart":"Erhaltung","art":"ruecklagenzufuehrung","betrag":{"cents":"600000","currency":"EUR"},"ruecklageId":"<uuid>"}]}'. Geld ist ein Objekt {cents, currency} (cents als Ziffern-String). art: kosten · einnahme · ruecklagenzufuehrung. Bei einem Objekt mit abweichendem Wirtschaftsjahr zusätzlich "beginn" und "ende" (YYYY-MM-DD).
objekt wirtschaftsplan bearbeiten <id>	POST	/api/objekt/{id}/wirtschaftsplan/entwurf	ja	Bearbeitet den Entwurf: bearbeiten legt eine neue Version an, die alte bleibt. --data '{"jahr":2027,"positionen":[{"kostenart":"Hausmeister","art":"kosten","betrag":{"cents":"1300000","currency":"EUR"},"verteilerschluessel":"mea"}]}' — die VOLLSTÄNDIGE Positionsliste, kein Teil-Patch. Geld ist ein Objekt {cents, currency}. Ohne bestehenden Plan: erst anlegen.
objekt wirtschaftsplan verwerfen <id>	POST	/api/objekt/{id}/wirtschaftsplan/verwerfen	ja	Verwirft eine Version im Status entwurf; ihre Positionen bleiben lesbar. --data '{"jahr":2027,"version":2}'. Ein beschlossener oder bereits verworfener Plan bleibt unverändert (Konflikt).
objekt wirtschaftsplan beschliessen <id>	POST	/api/objekt/{id}/wirtschaftsplan/beschluss	ja	Beschließt eine Version im Status entwurf: bindet sie an den tragenden Beschluss und setzt sie auf beschlossen (beschliesse_wirtschaftsplan). --data '{"jahr":2025,"version":2}' --beschluss <ref> (landet als beschlussRef). Die Referenz (beschluss-gegenstand:<uuid>) stammt aus casa objekt beschluss list; der Beschluss muss tragend sein, sonst bleibt der Plan Entwurf (Konflikt). Beschlossen wird nur die höchste Version des Jahres; dieselbe Referenz noch einmal ist ein No-op (bereits_beschlossen). Die Bindung ist unveränderlich.
objekt wirtschaftsplan uebernehmen <id>	POST	/api/objekt/{id}/wirtschaftsplan/hausgeld-soll	ja	Übernimmt den beschlossenen Wirtschaftsplan ins Hausgeld-Soll und stellt es fällig (uebernehme_wirtschaftsplan_ins_hausgeld_soll). --data '{"jahr":2025,"geldkreis":"weg_hausgeld"}' — ohne Zahlen: der Monatsbetrag ist der Jahresanteil je Einheit auf zwölf Monate, die Rücklage wird getrennt geführt. Rückwirkende Differenzen kommen nur als Vorschlag zurück und werden nicht gebucht (Quittierung: casa objekt hausgeld differenz). Ohne eigenen Plan im Jahr gilt der letzte beschlossene Plan weiter — gilt nur, wenn der Beschluss sie trägt; die Antwort nennt quelle (eigener_plan \	fortgeltung) und quelleJahr.
beschluss status <id>	POST	/api/beschluss/{id}/status	ja	Schreibt den Lebenszyklus-Status eines Beschlusses fort (neue Zeile im Verlauf, kein Überschreiben). --data '{"nachStatus":"bestandskraeftig","grund":"Anfechtungsfrist abgelaufen"}' — oder kurz --data '{}' --nach <status> --grund <text>. Unzulässige Übergänge werden abgelehnt; nichtig ist ein Endzustand. Hinweis: bestandskraeftig wird frühestens nach anfechtungsfristEnde gesetzt (steht in objekt beschluss list; Hinweis, keine Sperre).
einheitengruppe list	GET	/api/einheitengruppe	ja	Listet Abrechnungskreise. --status alle\	aktiv\	archiviert (Default aktiv), --propertyId <uuid>.
einheitengruppe get <id>	GET	/api/einheitengruppe/{id}	ja	Liest EINEN Abrechnungskreis samt Mitgliedschaften. --asOf <YYYY-MM-DD>.
einheitengruppe create	POST	/api/einheitengruppe	ja	Legt einen Abrechnungskreis an einem aktiven Objekt an. Braucht --data <json> mit propertyId, name, groupKind.
einheitengruppe update <id>	PATCH	/api/einheitengruppe/{id}	ja	Ändert name/groupKind eines Kreises. Braucht --data <json>. (propertyId ist nicht änderbar.)
einheitengruppe archive <id>	POST	/api/einheitengruppe/{id}/archive	ja	Archiviert einen Abrechnungskreis (archived_at statt Löschen).
einheitengruppe mitglied add <id>	POST	/api/einheitengruppe/{id}/mitglied	ja	Nimmt eine Einheit ab Datum in den Kreis auf. --einheit <uuid> --ab <YYYY-MM-DD> [--bis <YYYY-MM-DD>] und --data '{}'.
einheitengruppe mitglied beenden <id>	POST	/api/einheitengruppe/{id}/mitglied/beenden	ja	Beendet die Mitgliedschaft einer Einheit zum Stichtag. --einheit <uuid> --bis <YYYY-MM-DD> und --data '{}'.
umlageschluessel list	GET	/api/umlageschluessel	ja	Listet Umlageschlüssel. --status alle\	aktiv\	archiviert (Default aktiv), --propertyId/--unitGroupId <uuid>.
umlageschluessel get <id>	GET	/api/umlageschluessel/{id}	ja	Liest EINEN Umlageschlüssel.
umlageschluessel create	POST	/api/umlageschluessel	ja	Legt einen Umlageschlüssel an einem aktiven Objekt an. Braucht --data <json> mit propertyId, keyType, name.
umlageschluessel update <id>	PATCH	/api/umlageschluessel/{id}	ja	Ändert keyType/name/config. Braucht --data <json>. (Scope über scope, propertyId nicht änderbar.)
umlageschluessel scope <id>	POST	/api/umlageschluessel/{id}/scope	ja	Setzt/löst den Abrechnungskreis-Scope. --kreis <uuid> (oder --data '{"unitGroupId":null}' zum Aufheben). HINWEIS: Der Scope wird gespeichert, aber von der Abrechnung noch NICHT ausgewertet — ein gescopter Schlüssel verteilt heute wie ein objektweiter.
umlageschluessel archive <id>	POST	/api/umlageschluessel/{id}/archive	ja	Archiviert einen Umlageschlüssel (archived_at statt Löschen).
umlageschluessel messdienst-import <id> <datei>	POST	/api/umlageschluessel/{id}/messdienst-import	ja	Importiert externe Messdienst-Festbeträge (CSV oder ARGE-D-Satz-Datei) in einen Umlageschlüssel vom Typ „extern". Braucht --propertyId, --periodFrom, --periodTo, --currency. Die Periode muss EXAKT der Abrechnungsperiode entsprechen, sonst bleibt der Import wirkungslos. Die Datei wird serverseitig geparst, das Format am Inhalt erkannt.
rechte assign-role	POST	/api/rechte/rolle	ja	Weist einem User eine Rolle zu. Braucht --data <json> mit userId, roleKey.
rechte set-objekt	POST	/api/rechte/objekt	ja	Setzt eine Objekt-Zuständigkeit. Braucht --data <json> mit userId, propertyId.
rechte revoke-objekt	POST	/api/rechte/objekt/entziehen	ja	Entzieht eine Objekt-Zuständigkeit. Braucht --data <json> mit userId, propertyId.
vertrag list	GET	/api/vertrag	ja	Listet Verträge. --status alle\	aktiv\	beendet (Default aktiv), --objektId <uuid>, --asOf <YYYY-MM-DD>.
vertrag get <id>	GET	/api/vertrag/{id}	ja	Liest EINEN Vertrag samt Konditionen-Zeitscheiben und Zahlungen.
vertrag create	POST	/api/vertrag	ja	Legt einen Vertrag samt initialer Zahlungs-Zeitscheibe an. Braucht --data <json> mit propertyId, contractNo, mieterPersonId, kaltmieteCents, currency. mieterPersonId ist die MIETPARTEI des Vertrags (seit #1965 Pflicht): die Rolle entsteht in derselben Transaktion, ein Vertrag ohne Mieter ist nicht mehr anlegbar; unbekannt, mandantenfremd oder archiviert ergibt 404. --idempotency-key <key> für wiederholungssichere Anlage.
vertrag end <id>	POST	/api/vertrag/{id}/end	ja	Beendet einen Vertrag zum Stichtag. Braucht --data '{"endDate":"YYYY-MM-DD"}'.
vertrag zahlung set <id>	POST	/api/vertrag/{id}/zahlung	ja	Wechselt die Konditionen/vereinbarten Zahlungen eines Vertrags als Zeitscheibe. Braucht --data '{"ab":"YYYY-MM-DD","kaltmieteCents":…,"currency":"EUR","payments":[…]}'. --idempotency-key <key> für wiederholungssichere Wechsel.
vertrag personen list <id>	GET	/api/vertrag/{id}/personen	ja	Liest die Kopfzahl-Historie eines Vertrags. --asOf <YYYY-MM-DD> (Stichtag für active).
vertrag personen set <id>	POST	/api/vertrag/{id}/personen	ja	Setzt/ändert die Personenzahl eines Vertrags ab Datum (Grenzen einschließlich). --ab <YYYY-MM-DD> und --data '{"personCount":3}'.
vertrag personen remove <id> <sliceId>	POST	/api/vertrag/{id}/personen/{sliceId}/remove	ja	Entfernt eine Personenzahl-Scheibe eines Vertrags; die Vorgängerin deckt die Lücke wieder. Die erste Scheibe bleibt (409 conflict — ändern mit vertrag personen set). Die sliceId liefert vertrag personen list.
mieterwechsel	POST	/api/mieterwechsel	ja	Führt einen Mieterwechsel auf einer Einheit aus (Altvertrag beenden -> Neuvertrag -> Zeitscheiben, eine Transaktion). Braucht --data mit unitId, altVertragId, endDate, contractNo, mieterPersonId, kaltmieteCents, currency. mieterPersonId ist die MIETPARTEI des Neuvertrags (seit #1910 Pflicht): die Rolle entsteht in derselben Transaktion, ein Vertrag ohne Mieter ist nicht mehr anlegbar. Zeitscheiben sind halb-offen: endDate = erster Tag OHNE den Altmieter, startDate = erster Tag MIT dem Neumieter (Default = endDate, nahtlos); früher ist Überlappung (Fehler), später ist Leerstand und braucht leerstandAkzeptiert: true. --idempotency-key <key> macht einen Retry wiederholungssicher.
mandat list	GET	/api/mandat	ja	Listet SEPA-Mandate. --status alle\	pending\	active\	revoked\	expired (Default alle), --vertragId/--personId <uuid>.
mandat get <id>	GET	/api/mandat/{id}	ja	Liest EIN SEPA-Mandat samt Vertrags-/Personen-Bezug.
mandat create	POST	/api/mandat	ja	Legt ein SEPA-Mandat zu einem Vertrag an (Status pending). Braucht --data <json> mit contractId, mandateRef. --idempotency-key <key> für wiederholungssichere Anlage.
mandat status <id>	POST	/api/mandat/{id}/status	ja	Führt den Mandatsstatus (active\	revoked\	expired). Braucht --data '{"status":"active"}'.
option list	GET	/api/option	ja	Listet Options-Zeilen. --scopeType tenant\	objekt\	einheit\	vertrag, --scopeId <uuid>, --key <k>.
option get	GET	/api/option/effective	ja	Löst den effektiven Wert eines Schlüssels auf. --key <k> (Pflicht), --objektId/--einheitId/--vertragId <uuid>.
option set	POST	/api/option	ja	Setzt/überschreibt eine Option. Braucht --data '{"scopeType":"tenant\	objekt\	einheit\	vertrag","scopeId":"<uuid>","key":"...","value":<json>}' (scopeId nur für nicht-tenant-Scopes).
onboarding	POST	/api/objekt	ja	Geführtes Onboarding: Objekt → Bankverbindungen → Gebäude → Einheiten → Verträge → Plausi-Gate. --file <plan.json> (sonst interaktiv), --protokoll <pfad> macht den Lauf wiederaufsetzbar. Ausgabe ist ein JSON-Protokoll des Angelegten.
instandhaltung auftrag erteilen <id>	POST	/api/instandhaltung/{id}/auftrag	ja	Erteilt den Auftrag des Vorgangs <id>, nachdem die Kostenfreigabe vollständig ist: ein Auftrag ohne gültige Freigabe wird nie erteilt (Konflikt). Beispiel: --data '{}' oder --data '{"auftragId":"<uuid>"}'. Optional auftragId; ohne Angabe gilt der lebende Auftrag des Vorgangs (keiner ⇒ not_found). Antwort: auftragId, auftragsnummer, erteiltAm und Befunde (Gestattung, Freistellung; sie sind Warnungen, die Erteilung läuft trotzdem).
instandhaltung ausfuehrung <id>	POST	/api/instandhaltung/{id}/auftrag/ausfuehrung	ja	Meldet die Ausführung des erteilten Auftrags des Vorgangs <id>. Beispiel: --data '{"ausgefuehrtAm":"2026-11-10","notiz":"Leitung ersetzt"}' (ausgefuehrtAm nicht nach heute und nicht vor der Erteilung; notiz optional, höchstens 500 Zeichen). Optional auftragId; ohne Angabe gilt der lebende Auftrag des Vorgangs (keiner ⇒ not_found). Antwort: auftragId und ausgefuehrtAm.
instandhaltung auftrag stornieren <id>	POST	/api/instandhaltung/{id}/auftrag/stornieren	ja	Storniert den Auftrag des Vorgangs <id> mit Grund. Beispiel: --data '{"grund":"Dienstleister abgesprungen"}' (grund 1 bis 200 Zeichen). Optional auftragId; ohne Angabe gilt der lebende Auftrag des Vorgangs (keiner ⇒ not_found). Nach der Freigabe fällt der Vorgang zurück in angebote_offen, eine neue Freigabe ist nötig. Antwort: auftragId und vorgangStatus.
instandhaltung rechnung <id>	POST	/api/instandhaltung/{id}/rechnung	ja	Verknüpft den Rechnungsbeleg mit dem ausgeführten Auftrag des Vorgangs <id>. Beispiel: --data '{"documentId":"<uuid>","rechnungsdatum":"2026-11-10"}'. Optional auftragId; ohne Angabe gilt der lebende Auftrag des Vorgangs (keiner ⇒ not_found). Befunde sperren nicht, die Verknüpfung gelingt und nennt sie; die harte Sperre der Zahlung ohne Freistellungsbescheinigung liegt im Zahlungsauftrag. Exit 0, "befunde" mit Code, Schwere und Text (freistellung-fehlt, rechnung-ueber-auftrag, gestattungsbeschluss-fehlt). Geld ist ein Objekt {cents, currency}. Antwort: rechnungId, betrag, auftragswert, abweichung, summeRechnungen, bauleistung, befunde.
instandhaltung abschliessen <id>	POST	/api/instandhaltung/{id}/abschluss	ja	Schließt den Vorgang <id> ab. Beispiel: --data '{}' oder --data '{"begruendung":"Maßnahme erledigt"}' (begruendung optional, höchstens 300 Zeichen). Läuft noch ein Auftrag, ist das ein Konflikt. Antwort: vorgangId, vonStatus, status, ereignisId, begruendung.
instandhaltung stornieren <id>	POST	/api/instandhaltung/{id}/stornieren	ja	Storniert den Vorgang <id> mit Grund. Beispiel: --data '{"grund":"Meldung irrtümlich"}' (grund 1 bis 200 Zeichen). Läuft noch ein Auftrag, ist das ein Konflikt. Antwort: vorgangId, vonStatus, status, ereignisId, begruendung.
fremdvertrag anlegen	POST	/api/fremdvertrag	ja	Legt einen Vertrag mit Dritten samt ersten Konditionen an. Beispiel: --data '{"propertyId":"<uuid>","art":"wartung","partnerPersonId":"<uuid>","bezeichnung":"Aufzugswartung","beginn":"2026-01-01","laufzeitEnde":"2026-12-31","kuendigungsfristMonate":3,"beitrag":{"cents":"30000","currency":"EUR"},"beitragIntervall":"quartalsweise"}' (art: versicherung \	wartung \	dienstleistung \	versorgung; Partner mit Rolle Kreditor oder Dienstleister; optional vertragsnummer, selbstbehalt nur bei Versicherung, bemerkung). Ohne Angabe zur Verlängerung gilt: ja, 12 Monate (oder die Vorgabe der Einstellung). Geld ist ein Objekt {cents, currency}. Antwort: vertragId und konditionen (Version 1). Wiederholungssicher mit --idempotency-key.
fremdvertrag konditionen <id>	POST	/api/fremdvertrag/{id}/konditionen	ja	Legt eine neue Konditions-Version für den Vertrag <id> an (kein Teil-Patch: jeder Schlüssel ist Pflicht, leer ist null). Beispiel: --data '{"gueltigAb":"2027-01-01","laufzeitEnde":"2027-12-31","kuendigungsfristMonate":3,"verlaengerungStillschweigend":true,"verlaengerungMonate":12,"beitrag":{"cents":"32000","currency":"EUR"},"beitragIntervall":"quartalsweise","selbstbehalt":null,"bemerkung":null}'. gueltigAb muss nach der letzten Version liegen. Geld ist ein Objekt {cents, currency}. Antwort: vertragId und konditionen (neue Version).
fremdvertrag kuendigen <id>	POST	/api/fremdvertrag/{id}/kuendigung	ja	Hält die Kündigung des Vertrags <id> fest. Beispiel: --data '{"wirksamZum":"2026-12-31","grund":"Anbieterwechsel"}' (wirksamZum nicht vor heute; grund optional, höchstens 200 Zeichen). Die Antwort nennt das früheste Vertragsende ("fruehestesEnde") und den spätesten Zugang ("spaetesterZugang") als Auskunft; sie sperrt nicht. Antwort: vertragId, ereignisId, wirksamZum, fruehestesEnde, spaetesterZugang.
fremdvertrag beenden <id>	POST	/api/fremdvertrag/{id}/beendigung	ja	Beendet den Vertrag <id>. Beispiel: --data '{"beendetAm":"2026-12-31","grund":"Vertragsende"}' (beendetAm nicht vor dem Beginn; grund optional, höchstens 200 Zeichen). Es gibt kein Löschen: ein beendeter Vertrag bleibt lesbar. Antwort: vertragId, ereignisId, beendetAm.
fremdvertrag frist entscheiden <id>	POST	/api/fremdvertrag/{id}/frist-entscheid	ja	Hält die Entscheidung zu einem Vertragsende des Vertrags <id> fest. Beispiel: --data '{"bezugEnde":"2026-12-31","entscheidung":"verlaengern","grund":"Konditionen passen"}' (entscheidung: verlaengern \	kuendigen \	neu_ausschreiben; grund optional). Danach verschwindet die Zeile aus "fremdvertrag fristen". Es wird nie eine Kündigung angelegt — die schreibt "fremdvertrag kuendigen". Antwort: vertragId, bezugEnde, entscheidung, ereignisId, kuendigungAngelegt (false), hinweis.
fremdvertrag dauerzahlung <id>	POST	/api/fremdvertrag/{id}/dauerzahlung	ja	Verknüpft den Vertrag <id> mit einer Dauerzahlung desselben Objekts. Beispiel: --data '{"dauerzahlungId":"<uuid>"}'. Weichen Beitrag und Dauerzahlung ab, steht in der Antwort der "befund" (beitragJahr, dauerzahlungJahr, differenz); er sperrt nicht, Exit 0. Geld ist ein Objekt {cents, currency}. Antwort: vertragId, dauerzahlungId, befund (null ohne Abweichung).
fremdvertrag dauerzahlung loesen <id>	POST	/api/fremdvertrag/{id}/dauerzahlung/loesen	ja	Löst die Verknüpfung des Vertrags <id> mit seiner Dauerzahlung. Beispiel: --data '{}'. Die Dauerzahlung selbst bleibt unberührt. Antwort: vertragId und dauerzahlungId (die bis eben verknüpfte).
fremdvertrag einstellung setzen	PUT	/api/fremdvertrag/einstellung	ja	Setzt die Einstellung der Verträge mit Dritten des Mandanten (alle sechs Werte, kein Teil-Patch). Braucht --data '{"vorlaufTage":90,"verlaengerungStillschweigendVorgabe":true,"verlaengerungMonateVorgabe":12,"schadenMeldefristTage":7,"schadenhonorarProzentBp":800,"schadenhonorarAktiv":true}' — vorlaufTage 1 bis 365, Verlängerung 1 bis 60 Monate, Meldefrist 1 bis 60 Tage, Schadenhonorar in Basispunkten (800 = 8,00 %). Nur ein Mensch mit dem Recht, Rollen und Rechte zu verwalten (sonst Exit 403). Antwort: einstellung, vorher, geaendert, geaendertVon, geaendertAm. Wiederholungssicher mit --idempotency-key.
schadenfall anlegen	POST	/api/schadenfall	ja	Erfasst einen Schadenfall (Status erfasst). Beispiel: --data '{"propertyId":"<uuid>","schadensdatum":"2026-11-01","schadenart":"Wasserschaden","beschreibung":"Rohrbruch im Keller, Wasser steht 5 cm hoch.","versicherungsvertragId":"<uuid>","instandhaltungVorgangId":"<uuid>"}' (schadensdatum nicht nach heute; beschreibung 10 bis 5000 Zeichen; optional unitId, versicherungsvertragId, instandhaltungVorgangId, jeweils desselben Objekts). Antwort: schadenfallId, nummer, status, selbstbehalt und befunde.
schadenfall melden <id>	POST	/api/schadenfall/{id}/meldung	ja	Hält die Meldung des Schadenfalls <id> an den Versicherer fest. Beispiel: --data '{"gemeldetAm":"2026-11-03","aktenzeichen":"AZ-4711"}' (gemeldetAm nicht nach heute und nicht vor dem Schadensdatum; optional versicherungsvertragId, wenn dem Fall noch keine Versicherung zugeordnet ist). Eine verstrichene Meldefrist warnt als Befund (meldefrist-verstrichen), aber die Meldung wird festgehalten, Exit 0. Antwort: schadenfallId, nummer, status (gemeldet), selbstbehalt, befunde.
schadenfall deckung <id>	POST	/api/schadenfall/{id}/deckung	ja	Erfasst die Deckungsentscheidung des Versicherers für den Schadenfall <id>. Beispiel: --data '{"entscheidung":"zugesagt","deckungAm":"2026-11-05","schadenssumme":{"cents":"500000","currency":"EUR"},"selbstbehalt":{"cents":"50000","currency":"EUR"}}' (entscheidung: zugesagt \	abgelehnt; deckungAm nicht nach heute und nicht vor der Meldung). Geld ist ein Objekt {cents, currency}. Antwort: schadenfallId, nummer, status, selbstbehalt, schadenssumme, uebergang, befunde.
schadenfall erstattung <id>	POST	/api/schadenfall/{id}/erstattung	ja	Ordnet einen Bankumsatz als Erstattung dem Schadenfall <id> zu. Beispiel: --data '{"bankAccountId":"<uuid>","bankTransactionId":"<uuid>","asOf":"2026-11-06","bankGlAccountNo":"1200","sachkontoNo":"4260","buchungstext":"Erstattung Gebäudeversicherung"}'. Die Buchung entsteht als Vorschlag und wird erst nach der Freigabe gebucht. Der Fall muss auf Deckung zugesagt oder reguliert stehen; ein Umsatz gehört höchstens einem Schadenfall. Antwort: schadenfallId, status, erstattung, bilanz (Integer-Strings in Cent), vorschlag.
schadenfall abschliessen <id>	POST	/api/schadenfall/{id}/abschluss	ja	Schließt den Schadenfall <id> ab. Beispiel: --data '{}' oder --data '{"begruendung":"Fall erledigt"}' (begruendung optional, höchstens 300 Zeichen; ohne Versicherungsbezug Pflicht). Antwort: schadenfallId, vonStatus, status, begruendung, bilanz, befund.

auth

casa auth check

Prüft den Token gegen GET /api/me (Tenant + User).

casa auth check

• Endpunkt: GET /api/me
• Token nötig: ja
• Body: keiner

beleg

casa beleg upload

Reicht einen Beleg über die echte Ingest-Vordertür ein (multipart/form-data). Antwort trägt documentId + outcome.

casa beleg upload <datei>

• Endpunkt: POST /api/beleg
• Token nötig: ja
• Argumente: <datei> (exakte Stelligkeit — zu viele sind ebenfalls ein Bedienfehler)
• Body: keiner

auswertung

casa auswertung saldenliste

Summen- und Saldenliste der Sachkonten EINES Objekts: je Konto Anfangsbestand, Soll- und Haben-Umsatz des Zeitraums und Endsaldo, gegliedert nach Kontenklassen mit Zwischensummen. Pflicht: --objekt <uuid> --von JJJJ-MM-TT --bis JJJJ-MM-TT. Optional --nurBewegt true (nur Konten mit mindestens einer Buchung IM Zeitraum; Konten mit Vortrag, aber ohne Bewegung entfallen dann ebenfalls — "gefilterteKonten" nennt ihre Zahl) und --format csv (Ausgabe ist dann die CSV-Datei auf stdout statt des JSON-Umschlags; Semikolon, Dezimalkomma, UTF-8 mit BOM — von deutschem Excel ohne Nacharbeit lesbar). Alle Cent-Felder sind Integer-STRINGS: eine Jahressumme überschreitet 2^53, als JSON-number verlöre sie Cents. Der Zeitraum ist PFLICHT — ohne "von" wäre jeder Anfangsbestand null.

casa auswertung saldenliste [--objekt <wert>] [--von <wert>] [--bis <wert>] [--nurBewegt <wert>] [--format <wert>]

• Endpunkt: GET /api/auswertung/saldenliste
• Token nötig: ja
• Query-Flags: --objekt, --von, --bis, --nurBewegt, --format
• Body: keiner

casa auswertung katalog

Listet die verfügbaren Auswertungen: Name, Titel, Zweck, Zeitbezug und Spalten. Der Name aus dieser Liste ist das Argument von "auswertung abrufen".

casa auswertung katalog

• Endpunkt: GET /api/auswertungen
• Token nötig: ja
• Body: keiner

casa auswertung abrufen

Ruft EINE Auswertung des Katalogs ab (Name aus "auswertung katalog"). Pflicht: --objekt <uuid> --von JJJJ-MM-TT --bis JJJJ-MM-TT. Optional --format csv (Ausgabe ist dann die CSV-Datei auf stdout statt des JSON-Umschlags; Semikolon, Dezimalkomma, UTF-8 mit BOM, und oben die Quellenangabe: Mandant, Objekt, Zeitraum, letzte berücksichtigte Buchung). Je nach Auswertung zusätzlich --stichtag (offene Posten), --nurBewegt true (Saldenliste), --konto/--beleg (Buchungsliste), --menge offen\|alle (offene Posten), --einheit/--eigentuemer/--abschlusslauf <uuid> (hausgeld-steuerzuarbeit: Einheit oder Eigentümer UND festgeschriebener Abschluss-Lauf; fremder oder unbekannter Lauf ⇒ not_found, nicht festgeschriebener oder stornierter ⇒ conflict, ohne --einheit leer); ein Filter, den die gewählte Auswertung nicht führt, ist ein benannter Bedienfehler statt eines still verworfenen Flags. Im JSON ist jede Zelle ein String: "spalten[i].typ" sagt, wie sie zu lesen ist (betrag = Integer-Cents, weil eine Jahressumme 2^53 überschreitet).

casa auswertung abrufen <auswertung> [--objekt <wert>] [--von <wert>] [--bis <wert>] [--stichtag <wert>] [--nurBewegt <wert>] [--konto <wert>] [--beleg <wert>] [--menge <wert>] [--einheit <wert>] [--eigentuemer <wert>] [--abschlusslauf <wert>] [--format <wert>]

• Endpunkt: GET /api/auswertungen/{auswertung}
• Token nötig: ja
• Argumente: <auswertung> (exakte Stelligkeit — zu viele sind ebenfalls ein Bedienfehler)
• Query-Flags: --objekt, --von, --bis, --stichtag, --nurBewegt, --konto, --beleg, --menge, --einheit, --eigentuemer, --abschlusslauf, --format
• Body: keiner

casa auswertung finanzstatus

Finanzstatus EINES Objekts. Pflicht: --objekt <uuid> UND genau einer der beiden Modi — --von JJJJ-MM-TT --bis JJJJ-MM-TT (Entwicklung der Geldkonten im Zeitraum: je Bank-/Kassen-/Rücklagenkonto Anfangsbestand, Zugänge, Abgänge, Endbestand und die Bewegungen mit laufendem Saldo NACH WERTSTELLUNG, dazu die Vermögensübersicht zum "bis"-Tag) ODER --stichtag JJJJ-MM-TT (nur die Vermögensübersicht: Geldkonten, offene Forderungen, offene Verbindlichkeiten, Reinvermögen). Beides zusammen oder keins von beidem ist 400 — ohne Zeitraum gäbe es keinen Anfangsbestand und damit keine Entwicklung. Alle Cent-Felder sind Integer-STRINGS: ein Jahresumsatz überschreitet 2^53, als JSON-number verlöre er Cents. "stimmt" (je Konto: Anfangsbestand + Zugänge − Abgänge = Endbestand) und "bilanzgleichgewicht" (Reinvermögen + Σ Sachkonten = 0) werden AUSGEWIESEN, nicht erzwungen — eine Schieflage soll sichtbar sein, nicht die Antwort verhindern.

casa auswertung finanzstatus [--objekt <wert>] [--stichtag <wert>] [--von <wert>] [--bis <wert>]

• Endpunkt: GET /api/auswertung/finanzstatus
• Token nötig: ja
• Query-Flags: --objekt, --stichtag, --von, --bis
• Body: keiner

casa auswertung ust-liste

Umsatzsteuer, Vorsteuer und Zahllast EINES Objekts über einen Zeitraum, je Steuersatz und Voranmeldungs-Periode. Pflicht: --objekt <uuid> --von JJJJ-MM-TT --bis JJJJ-MM-TT. Optional: --rhythmus monat\|quartal\|jahr (Default quartal), --je-konto true (Detail je Konto und Satz; sonst ist "zeilen" null). Alle Beträge sind Integer-STRINGS in Cent, der Steuersatz ein String in ganzen Prozent. Eine Buchung ohne Steuerschlüssel auf einem steuerpflichtigen Konto erscheint unter "befunde", NICHT als steuerfreier Umsatz; ein Objekt ohne umsatzsteuerpflichtige Umsätze liefert eine leere Liste samt "hinweis".

casa auswertung ust-liste [--objekt <wert>] [--von <wert>] [--bis <wert>] [--rhythmus <wert>] [--je-konto <wert>]

• Endpunkt: GET /api/auswertung/ust-liste
• Token nötig: ja
• Query-Flags: --objekt, --von, --bis, --rhythmus, --je-konto
• Body: keiner

casa auswertung einnahmen-ausgaben

Liest das Einnahmen-/Ausgaben-Journal eines Objekts für einen Zeitraum — je Geldbewegung eine Zeile mit Gegenkonto, Beleg und Netto/USt/Brutto, dazu die Summen je Gegenkonto. PFLICHT: --objekt <objektId> --von <YYYY-MM-DD> --bis <YYYY-MM-DD>. --je-konto <kontonummer> grenzt auf EIN Gegenkonto ein. Alle Cent-Felder sind Integer-STRINGS. Eine Umbuchung zwischen zwei Geldkonten ist weder Einnahme noch Ausgabe — sie steht in "umbuchungen"; "ohneGeldkontoSeite" zählt die Sätze des Zeitraums ohne Geldkonto-Zeile (Sollstellungen). Ein Bestandsvortrag (entry_type eroeffnung) ist KEINE Einnahme — das Geld war schon da; er steht in "eroeffnungen". "ustHerkunft" sagt je Zeile, ob die USt GEBUCHT oder aus dem Satz ABGELEITET ist. "verrechnet": true kennzeichnet eine Zeile, die innerhalb ihres Satzes gegen die Geldkonto-Seite verrechnet wurde (Einbehalt, Abzug) — sie zählt voll als Einnahme bzw. Ausgabe, und "geldkonten" nennt das Konto, gegen das verrechnet wurde. Unbekanntes oder fremdes Objekt ⇒ error.code "not_found" bei Exit 5 (kein Existenz-Orakel).

casa auswertung einnahmen-ausgaben [--objekt <wert>] [--von <wert>] [--bis <wert>] [--je-konto <wert>]

• Endpunkt: GET /api/auswertung/einnahmen-ausgaben
• Token nötig: ja
• Query-Flags: --objekt, --von, --bis, --je-konto
• Body: keiner

casa auswertung einnahmen-ueberschuss

Einnahmen-Überschuss-Aufstellung EINES Objekts für EIN Kalenderjahr (Zufluss/Abfluss, § 11 EStG): Einnahmen und Werbungskosten je Gruppe (Miete, Umlagen, umlagefähige Kosten, Instandhaltung, Verwaltung, Sonstige), Brutto/USt/Netto und Überschuss. Pflicht: --objekt <uuid> --jahr JJJJ. Optional --eigentuemer <personId> (sein Anteil nach Eigentumsanteil, Rest-Cent nach größtem Rest; fehlt ⇒ Objekt gesamt) und --format csv (Ausgabe ist dann die CSV-Datei auf stdout — für Eigentümer oder Steuerberater). Kautionen, durchlaufende Posten, Rücklagen und Einlagen/Entnahmen des Eigentümers zählen nicht. Betrags-Zellen sind Integer-Cent-STRINGS. Unbekanntes/fremdes Objekt oder Person ohne Anteil ⇒ not_found (Exit 5); Einheit ohne Eigentümer oder uneinheitliche Anteile ⇒ invalid_request (HTTP 422).

casa auswertung einnahmen-ueberschuss [--objekt <wert>] [--jahr <wert>] [--eigentuemer <wert>] [--format <wert>]

• Endpunkt: GET /api/auswertung/einnahmen-ueberschuss
• Token nötig: ja
• Query-Flags: --objekt, --jahr, --eigentuemer, --format
• Body: keiner

sondereigentumsverwaltung

casa sondereigentumsverwaltung stand

Monatsstand der Sondereigentumsverwaltung EINES Objekts. Pflicht: --objekt <uuid> UND --monat JJJJ-MM. Je SEV-Wohnung: Stand der fünf Pflicht-Schritte (Mietgutschrift → Vergütung → Hausgeld → Sonderrücklage → Auszahlung), Saldo des Eigentümers, Sockelbetrag, Sonderrücklage, Unterdeckungen mit Betrag und der nächste fällige Schritt. Wohnung und Eigentümer stehen mit Namen da, nicht als Kennung. Ein Wert ohne Quelle steht auf "nicht verfügbar" — NIE auf 0 und nie auf "erledigt"; vollstaendig: false sagt es für die ganze Antwort. Solange die SEV-Kette nicht eingerichtet ist, ist "wohnungen" LEER und der Grund steht in "hinweise" — das ist ausdrücklich nicht die Aussage "dieses Objekt hat keine SEV-Wohnungen". Cent-Felder sind Integer-STRINGS oder null, nie JSON-numbers.

casa sondereigentumsverwaltung stand [--objekt <wert>] [--monat <wert>]

• Endpunkt: GET /api/sondereigentumsverwaltung/stand
• Token nötig: ja
• Query-Flags: --objekt, --monat
• Body: keiner

honorar

casa honorar berechnen

Verwalterhonorar EINES Objekts für EINEN Monat als Vorschau — Positionsaufstellung je Einheit, Basis und Zuschlag, dazu Netto, Umsatzsteuer und Brutto. Pflicht: --objekt <uuid> --monat JJJJ-MM. Gerechnet wird mit der Zeitscheibe der Honorarvereinbarung, die den ANGEFRAGTEN Monat abdeckt: ändert sich der Satz zum 1. Juli, gilt für Juni der alte und für Juli der neue. Alle Cent-Felder und der USt-Satz sind Integer-STRINGS, nie JSON-numbers. BUCHT NICHTS — die Ausgabe ist eine Vorschau, keine Forderung; die Sollstellung des Honorars ist ein eigener Schritt mit eigener Freigabe. Die Vereinbarung selbst wird als Objekt-Option hinterlegt: casa option set --data '{"scopeType":"objekt","scopeId":"<objekt>","key":"verwalterhonorar.vereinbarungen","value":[ <Zeitscheiben> ]}' — Wert ist eine LISTE von Zeitscheiben (gueltigAb/gueltigBis inklusive, berechnungsart, pauschaleJeEinheitentyp, satzBasispunkte, mindestbetrag, hoechstbetrag, leerstandMindestbetrag, zuschlaege, umsatzsteuersatzProzent); Beträge als {"cents":"2500","currency":"EUR"}, Sätze als Integer-Strings.

casa honorar berechnen [--objekt <wert>] [--monat <wert>]

• Endpunkt: GET /api/honorar/vorschau
• Token nötig: ja
• Query-Flags: --objekt, --monat
• Body: keiner

casa honorar sonderleistung erfassen

Erfasst EINE Sonderleistung des Verwalters (z. B. Mahnbescheid). Braucht --data '{"propertyId":"<uuid>","schluessel":"mahnbescheid","leistungsdatum":"YYYY-MM-DD","menge":"1"}'; optional "unitId" (Einheit des Objekts) und "notiz". Menge als Dezimal-STRING mit Punkt (je Stunde z. B. "1.25"). Preis und USt kommen aus dem Katalog des Objekts, hinterlegt als Objekt-Option: casa option set --data '{"scopeType":"objekt","scopeId":"<objekt>","key":"verwalterhonorar.sonderleistungen","value":[{"schluessel":"mahnbescheid","bezeichnung":"Mahnbescheid","preisart":"fest","preis":{"cents":"5000","currency":"EUR"},"umsatzsteuersatzProzent":"19"}]}' (preisart fest \| je_stunde \| je_einheit). Mit --idempotency-key wiederholungssicher: derselbe Schlüssel legt die Leistung nur einmal an.

casa honorar sonderleistung erfassen --data '<json>'

• Endpunkt: POST /api/honorar/sonderleistungen
• Token nötig: ja
• Body: Pflicht (--data '<json>')

casa honorar sonderleistung serie

Serienerfassung: EINE Leistung mit Preis je Einheit für jede Einheit, die am Leistungsdatum zum Objekt gehört — in einem Schritt (z. B. § 35a-Bescheinigung für alle Wohnungen). Braucht --data '{"propertyId":"<uuid>","schluessel":"bescheinigung_35a","leistungsdatum":"YYYY-MM-DD"}'; optional "notiz". Dieselbe Serie (Objekt, Leistung, Leistungsdatum) entsteht nur einmal — eine Wiederholung legt nichts an und meldet "bereitsErfasst":true.

casa honorar sonderleistung serie --data '<json>'

• Endpunkt: POST /api/honorar/sonderleistungen/serie
• Token nötig: ja
• Body: Pflicht (--data '<json>')

casa honorar sonderleistung stornieren

Storniert eine erfasste Sonderleistung — sie bleibt auffindbar, zählt aber in keiner Honorarrechnung mehr. Braucht --data '{"propertyId":"<uuid>","sonderleistungId":"<uuid>","grund":"<text>"}'.

casa honorar sonderleistung stornieren --data '<json>'

• Endpunkt: POST /api/honorar/sonderleistungen/storno
• Token nötig: ja
• Body: Pflicht (--data '<json>')

casa honorar sonderleistung vorlage

Kopiert den Vorlage-Katalog des Mandanten als eigenen Sonderleistungs-Katalog an ein Objekt (für neue Verträge). Braucht --data '{"propertyId":"<uuid>"}'. Die Vorlage selbst ist eine Mandanten-Option: casa option set --data '{"scopeType":"tenant","key":"verwalterhonorar.sonderleistungen","value":[ <Einträge> ]}'. Eine Kopie, kein Verweis — eine spätere Änderung der Vorlage ändert den Katalog des Objekts nicht.

casa honorar sonderleistung vorlage --data '<json>'

• Endpunkt: POST /api/honorar/sonderleistungen/vorlage
• Token nötig: ja
• Body: Pflicht (--data '<json>')

casa honorar anpassen

Passt die Honorarvereinbarung EINES Objekts an: neue Zeitscheibe ab --ab JJJJ-MM-01, die laufende endet am Vortag. Pflicht: --objekt <uuid> --ab JJJJ-MM-01 --grundlage beschluss\|zustimmung\|klausel --begruendung "<Text>" und die neue Vereinbarung als --data '{"neueVereinbarung":{"berechnungsart":"pauschal_je_einheit","pauschaleJeEinheitentyp":{"wohnung":{"cents":"2800","currency":"EUR"}},"satzBasispunkte":null,"mindestbetrag":null,"hoechstbetrag":null,"leerstandMindestbetrag":null,"zuschlaege":[],"umsatzsteuersatzProzent":"19"}}' (ohne gueltigAb/gueltigBis; Beträge als {"cents":"2800","currency":"EUR"}, Sätze als Integer-Strings). WEG nur mit Beschluss: --grundlage beschluss --beschluss <uuid> (der Beschluss muss angenommen oder bestandskräftig sein und zum Objekt gehören). Zustimmung des Eigentümers: --zustimmung-am JJJJ-MM-TT. Die Wirksamkeit gilt zum Monatsersten (ein Teilmonat ist nicht vereinbar); KEINE Rückwirkung auf bereits gestellte Honorarmonate. Die Erstanlage der Vereinbarung bleibt casa option set (Schlüssel verwalterhonorar.vereinbarungen). Die Antwort nennt neue und geschlossene Scheibe, den Vergleich alt/neu (Änderung in Basispunkten) und Hinweise. Mit --idempotency-key wiederholungssicher.

casa honorar anpassen [--objekt <wert>] [--ab <wert>] [--grundlage <wert>] [--beschluss <wert>] [--zustimmung-am <wert>] [--begruendung <wert>] --data '<json>'

• Endpunkt: POST /api/honorar/anpassungen
• Token nötig: ja
• Body-Flags: --objekt → Body-Feld propertyId, --ab → Body-Feld wirksamAb, --grundlage → Body-Feld grundlage, --beschluss → Body-Feld beschlussId, --zustimmung-am → Body-Feld zustimmungAm, --begruendung → Body-Feld begruendung
• Body: Pflicht (--data '<json>')

casa honorar anpassungen

Geschichte der Honorar-Anpassungen EINES Objekts, neueste zuerst (Pflicht: --objekt <uuid>): Wirksamkeit, Grundlage, Beschluss, Begründung sowie alte und neue Zeitscheibe. Ohne den Akteur, der sie vorgenommen hat. Cent-Beträge und Sätze sind Integer-STRINGS.

casa honorar anpassungen [--objekt <wert>]

• Endpunkt: GET /api/honorar/anpassungen
• Token nötig: ja
• Query-Flags: --objekt
• Body: keiner

casa honorar rentabilitaet

Rentabilität EINES Objekts über einen Zeitraum ganzer Monate. Pflicht: --objekt <uuid> --von JJJJ-MM --bis JJJJ-MM (höchstens 24 Monate). Liefert Ertrag, Aufwand, Deckungsbeitrag, Marge (Basispunkte), Kapazitätsanteil und Urteil samt den geltenden Kalkulationssätzen. Ertrag ist die Honorarvorschau je Monat (Sonderleistungen mit); Aufwand ist erfasste Zeit mal Kalkulationssatz. Die Sätze kommen aus der Mandanten-Option verwalterhonorar.kalkulation (Vorgabe 60,00 € je Stunde, 136 Stunden je Monat — als Default und nicht als Wahrheit), gesetzt mit casa option set. Ohne erfasste Zeit lautet das Urteil "nicht beurteilbar", nie "wirtschaftlich". Alle Cent-Felder und Basispunkte sind Integer-STRINGS; die Marge ist null ohne Ertrag. Liest nur, bucht nichts.

casa honorar rentabilitaet [--objekt <wert>] [--von <wert>] [--bis <wert>]

• Endpunkt: GET /api/honorar/rentabilitaet
• Token nötig: ja
• Query-Flags: --objekt, --von, --bis
• Body: keiner

zaehler

casa zaehler list

Listet die Zähler des Mandanten mit Einheitsnummer, Zählerart, Maßeinheit und Archivstand. Optional --objekt <uuid> --einheit <uuid> --zaehlerart <art> --archiveScope aktiv\|archiviert\|alle (Default aktiv). Ein fremdes oder unbekanntes Objekt ist not_found, keine leere Liste.

casa zaehler list [--objekt <wert>] [--einheit <wert>] [--zaehlerart <wert>] [--archiveScope <wert>]

• Endpunkt: GET /api/zaehler
• Token nötig: ja
• Query-Flags: --objekt, --einheit, --zaehlerart, --archiveScope
• Body: keiner

casa zaehler ablesungen

Ablesungs-Historie EINES Zählers (Positional <id>), aufsteigend nach Ablesezeitpunkt. Optional --von JJJJ-MM-TT --bis JJJJ-MM-TT (beide inklusiv). Zählerstände sind Dezimal-STRINGS mit Punkt und Skala 3 (z. B. "161.700"), nie JSON-numbers. Ein unbekannter oder fremder Zähler ist not_found.

casa zaehler ablesungen <id> [--von <wert>] [--bis <wert>]

• Endpunkt: GET /api/zaehler/{id}/ablesungen
• Token nötig: ja
• Argumente: <id> (exakte Stelligkeit — zu viele sind ebenfalls ein Bedienfehler)
• Query-Flags: --von, --bis
• Body: keiner

casa zaehler verbrauch

Verbrauch der Zähler EINES Objekts für einen Zeitraum, je Zähler und je (Einheit, Zählerart). Pflicht: --objekt <uuid> --von JJJJ-MM-TT --bis JJJJ-MM-TT. Stände und Verbrauch sind Dezimal-STRINGS mit Punkt (Skala 3). Der Anfangsstand ist der letzte Stand bis zum Periodenbeginn (auch aus dem Vorjahr), der Endstand der letzte Stand bis zum Periodenende. Fehlt eine Grenze, ist das ein ehrlicher Fehlbestand: "vollstaendig": false mit den "fehlend"-Gründen (anfangsstand/endstand) — der Verbrauch wird NICHT geschätzt oder interpoliert.

casa zaehler verbrauch [--objekt <wert>] [--von <wert>] [--bis <wert>]

• Endpunkt: GET /api/zaehler/verbrauch
• Token nötig: ja
• Query-Flags: --objekt, --von, --bis
• Body: keiner

casa zaehler zwischenstand

Zwischenstand-VORSCHLAG eines Zählers (Positional <id>) für einen Stichtag (Mieterwechsel): linear nach Kalendertagen zwischen dem letzten Stand davor und dem ersten danach, mit Begründung. Pflicht: --stichtag JJJJ-MM-TT. Der Zwischenstand ist ein VORSCHLAG und wird nicht gebucht; übernehmen heißt casa zaehler ablesen --anlass zwischenablesung --erhebungsart schaetzung. Der Abrechnungslauf bleibt ohne erklärten Schnitt fail-closed. Kein Vorschlag (mit "code"): stand-vorhanden, kein-vorher-wert, kein-nachher-wert, stand-faellt, luecke-zu-lang (mehr als 400 Tage). Stände sind Dezimal-STRINGS mit Punkt (Skala 3). Ein unbekannter oder fremder Zähler ist not_found.

casa zaehler zwischenstand <id> [--stichtag <wert>]

• Endpunkt: GET /api/zaehler/{id}/zwischenstand
• Token nötig: ja
• Argumente: <id> (exakte Stelligkeit — zu viele sind ebenfalls ein Bedienfehler)
• Query-Flags: --stichtag
• Body: keiner

casa zaehler pflicht

Prüft, ob für ein Objekt und eine Zählerart eine Verbrauchserfassung nach HeizkostenV Pflicht ist (ab 3 Wohneinheiten, mit Ausnahme-Option am Objekt). Pflicht: --objekt <uuid> --zaehlerart <art> (waerme, wasser_warm, wasser_kalt, strom, …). Antwort "pflicht": ja \| nein \| ausnahme \| nicht-heizkostenv, dazu "hinweise". Die Pflichtprüfung ist ein Hinweis und blockiert nichts. Ein fremdes oder unbekanntes Objekt ist not_found, kein "nein".

casa zaehler pflicht [--objekt <wert>] [--zaehlerart <wert>]

• Endpunkt: GET /api/zaehler/pflicht
• Token nötig: ja
• Query-Flags: --objekt, --zaehlerart
• Body: keiner

casa zaehler anlegen

Legt einen Zähler an. Pflicht: --objekt <uuid> --art <Zählerart, z. B. wasser_kalt\|wasser_warm\|waerme\|strom>. Optional --einheit <uuid> (ohne: Allgemein-Zähler), --nummer <feste Zählernummer> ODER --praefix <Nummernkreis> (nie beides), --turnusjahr <Jahr> (für den Vorgabe-Kreis), --masseinheit <z. B. m3\|kwh>. Objekt und Standort (Einheit) sind nach der Anlage fest. Nummernkreis als Vorgabe: ohne --nummer und --praefix vergibt der Server KW\|WW\|HZ\|ST-<Turnusjahr>-NNN (KW kalt, WW warm, HZ Wärme, ST Strom), fortlaufend im Objekt. Die Antwort nennt die vergebene Zählernummer. Mit --idempotency-key wiederholungssicher.

casa zaehler anlegen [--objekt <wert>] [--einheit <wert>] [--art <wert>] [--nummer <wert>] [--praefix <wert>] [--turnusjahr <wert>] [--masseinheit <wert>] --data '<json>'

• Endpunkt: POST /api/zaehler
• Token nötig: ja
• Body-Flags: --objekt → Body-Feld propertyId, --einheit → Body-Feld unitId, --art → Body-Feld meterType, --nummer → Body-Feld meterNo, --praefix → Body-Feld meterNoPrefix, --turnusjahr → Body-Feld turnusjahr, --masseinheit → Body-Feld unitOfMeasure
• Body: Pflicht (--data '<json>')

casa zaehler sammelanlage

Legt denselben Zählertyp für mehrere Einheiten EINES Objekts an (höchstens 500). Pflicht: --objekt <uuid> --art <Zählerart> und die Einheiten als --data '{"einheiten":[{"unitId":"<uuid>"},{"unitId":"<uuid>","meterNo":"<Nummer>"}]}'. Optional --praefix, --turnusjahr, --masseinheit. Je Einheit „angelegt" oder „vorhanden": eine Wiederholung legt nur Fehlendes an. Objekt und Standort (Einheit) sind nach der Anlage fest. Nummernkreis als Vorgabe: ohne --nummer und --praefix vergibt der Server KW\|WW\|HZ\|ST-<Turnusjahr>-NNN (KW kalt, WW warm, HZ Wärme, ST Strom), fortlaufend im Objekt. Mit --idempotency-key wiederholungssicher.

casa zaehler sammelanlage [--objekt <wert>] [--art <wert>] [--praefix <wert>] [--turnusjahr <wert>] [--masseinheit <wert>] --data '<json>'

• Endpunkt: POST /api/zaehler/sammelanlage
• Token nötig: ja
• Body-Flags: --objekt → Body-Feld propertyId, --art → Body-Feld meterType, --praefix → Body-Feld meterNoPrefix, --turnusjahr → Body-Feld turnusjahr, --masseinheit → Body-Feld unitOfMeasure
• Body: Pflicht (--data '<json>')

casa zaehler aendern

Ändert Stammfelder EINES Zählers (Positional <id>): mindestens eines von --art, --nummer, --masseinheit. Objekt und Standort sind nach der Anlage fest (nicht änderbar); ein Zähler wird stattdessen getauscht oder stillgelegt. Ein unbekannter oder fremder Zähler ist not_found. Mit --idempotency-key wiederholungssicher.

casa zaehler aendern <id> [--art <wert>] [--nummer <wert>] [--masseinheit <wert>] --data '<json>'

• Endpunkt: PATCH /api/zaehler/{id}
• Token nötig: ja
• Argumente: <id> (exakte Stelligkeit — zu viele sind ebenfalls ein Bedienfehler)
• Body-Flags: --art → Body-Feld meterType, --nummer → Body-Feld meterNo, --masseinheit → Body-Feld unitOfMeasure
• Body: Pflicht (--data '<json>')

casa zaehler archivieren

Legt EINEN Zähler still (Positional <id>). Ein Zähler mit Ablesungen lässt sich erst nach dem Stand zum jüngsten Periodenende stilllegen (Konflikt OFFENE_ABLESUNG). Ein zweites Archivieren ist kein Fehler: die Antwort trägt bereitsArchiviert=true. Objekt und Standort bleiben fest. Mit --idempotency-key wiederholungssicher.

casa zaehler archivieren <id>

• Endpunkt: POST /api/zaehler/{id}/archiv
• Token nötig: ja
• Argumente: <id> (exakte Stelligkeit — zu viele sind ebenfalls ein Bedienfehler)
• Body: keiner

casa zaehler ablesen

Erfasst eine Ablesung an EINEM Zähler (Positional <id>). Pflicht: --stand <Dezimalzahl mit PUNKT, höchstens 3 Nachkommastellen, z. B. 161.700; ein Komma ist ein Fehler> --am <YYYY-MM-DD oder ISO-Zeitpunkt; ein Kalendertag zählt als 00:00 UTC> --anlass turnus\|wechsel\|zwischenablesung. Optional --erhebungsart <ablesung\|schaetzung\|portal> (Standard ablesung). Plausibilitäts-Warnungen (Ausreißer, Verbrauch null) und Hinweise (Ablesefenster) stehen in der Antwort unter data.plausibilitaet; sie sind KEIN Fehler, der Stand ist dann gespeichert. Ein Stand unter dem Vorstand oder ein bereits belegter Zeitpunkt ist ein Konflikt, nichts wird gespeichert. Die Zwischenablesung am Tag des Mieterwechsels (--anlass zwischenablesung) ist die Voraussetzung der Verbrauchs-Zuordnung je Vertrag. Mit --idempotency-key wiederholungssicher.

casa zaehler ablesen <id> [--stand <wert>] [--am <wert>] [--anlass <wert>] [--erhebungsart <wert>] --data '<json>'

• Endpunkt: POST /api/zaehler/{id}/ablesungen
• Token nötig: ja
• Argumente: <id> (exakte Stelligkeit — zu viele sind ebenfalls ein Bedienfehler)
• Body-Flags: --stand → Body-Feld reading, --am → Body-Feld readAt, --anlass → Body-Feld occasion, --erhebungsart → Body-Feld source
• Body: Pflicht (--data '<json>')

casa zaehler tauschen

Tauscht EINEN Zähler in einem Schritt (Positional <id> = der ALTE Zähler): Endstand des Altzählers, neuer Zähler, Anfangsstand, Altzähler archiviert. Die Antwort nennt die Id des neuen Zählers (data.neuZaehlerId). Pflicht: --am <YYYY-MM-DD oder ISO-Zeitpunkt> --endstand <Stand des alten Zählers, Dezimalzahl mit PUNKT, z. B. 250.000>. Optional --anfangsstand <Stand des neuen Zählers, Standard 0.000> und --neue-nummer <Zählernummer des Neugeräts>. Der Endstand darf den letzten erfassten Stand nicht unterschreiten (Konflikt). Mit --idempotency-key wiederholungssicher.

casa zaehler tauschen <id> [--am <wert>] [--endstand <wert>] [--anfangsstand <wert>] [--neue-nummer <wert>] --data '<json>'

• Endpunkt: POST /api/zaehler/{id}/tausch
• Token nötig: ja
• Argumente: <id> (exakte Stelligkeit — zu viele sind ebenfalls ein Bedienfehler)
• Body-Flags: --am → Body-Feld readAt, --endstand → Body-Feld endReading, --anfangsstand → Body-Feld startReading, --neue-nummer → Body-Feld newMeterNo
• Body: Pflicht (--data '<json>')

casa zaehler berichtigen

Berichtigt den Stand EINER Ablesung (Positional <ablesungId>, die Id steht in casa zaehler ablesungen <zaehlerId>): --stand <richtiger Stand, Dezimalzahl mit PUNKT, z. B. 151.700>, optional --grund <Text>. Zeitpunkt und Anlass bleiben. Die Antwort nennt stand und vorherigerStand; die Plausibilität wird neu gerechnet (Warnungen unter data.plausibilitaet sind KEIN Fehler). Eine Ablesung, auf der eine festgeschriebene Abrechnung beruht, ist gesperrt (Konflikt ABRECHNUNG_FESTGESCHRIEBEN): Eine Korrektur läuft dann über eine neue Fassung des Abrechnungslaufs. Mit --idempotency-key wiederholungssicher.

casa zaehler berichtigen <ablesungId> [--stand <wert>] [--grund <wert>] --data '<json>'

• Endpunkt: PATCH /api/ablesung/{ablesungId}
• Token nötig: ja
• Argumente: <ablesungId> (exakte Stelligkeit — zu viele sind ebenfalls ein Bedienfehler)
• Body-Flags: --stand → Body-Feld reading, --grund → Body-Feld grund
• Body: Pflicht (--data '<json>')

zeit

casa zeit erfassen

Trägt Zeit nachträglich ein. Pflicht: --objekt <uuid> --datum JJJJ-MM-TT (nicht in der Zukunft) --minuten <ganze Zahl, 1 bis 1440> --art telefonat\|aussendienst\|schriftverkehr\|versammlung\|verwaltung\|sonstiges. Optional --notiz "<Text>", --bezug-art objekt\|anliegen\|sonderleistung und --bezug-id <uuid>. Objektbezug ist Pflicht; die Zeit ist die eigene. Über 10 Stunden kommt ein Hinweis. Mit --idempotency-key wiederholungssicher.

casa zeit erfassen [--objekt <wert>] [--datum <wert>] [--minuten <wert>] [--art <wert>] [--notiz <wert>] [--bezug-art <wert>] [--bezug-id <wert>] --data '<json>'

• Endpunkt: POST /api/zeit
• Token nötig: ja
• Body-Flags: --objekt → Body-Feld propertyId, --datum → Body-Feld leistungsdatum, --minuten → Body-Feld dauerMinuten, --art → Body-Feld taetigkeitsart, --notiz → Body-Feld notiz, --bezug-art → Body-Feld bezugArt, --bezug-id → Body-Feld bezugId
• Body: Pflicht (--data '<json>')

casa zeit start

Startet einen Timer. Pflicht: --objekt <uuid> --art telefonat\|aussendienst\|schriftverkehr\|versammlung\|verwaltung\|sonstiges. Optional --notiz, --bezug-art, --bezug-id. Objektbezug ist Pflicht; mehrere Timer dürfen gleichzeitig laufen (läuft einer an einem anderen Objekt, kommt nur ein Hinweis). Die Zeit ist die eigene. Die Antwort nennt die zeitId für casa zeit stopp <id>.

casa zeit start [--objekt <wert>] [--art <wert>] [--notiz <wert>] [--bezug-art <wert>] [--bezug-id <wert>] --data '<json>'

• Endpunkt: POST /api/zeit/start
• Token nötig: ja
• Body-Flags: --objekt → Body-Feld propertyId, --art → Body-Feld taetigkeitsart, --notiz → Body-Feld notiz, --bezug-art → Body-Feld bezugArt, --bezug-id → Body-Feld bezugId
• Body: Pflicht (--data '<json>')

casa zeit stopp

Stoppt einen EIGENEN laufenden Timer (Positional <id> = zeitId aus zeit start oder zeit laufend). Die Dauer wird aus Beginn und Ende gerechnet. Ein zweites Stoppen ist ein Konflikt; der Timer eines anderen Mitarbeiters ist nicht da (not_found).

casa zeit stopp <id>

• Endpunkt: POST /api/zeit/{id}/stopp
• Token nötig: ja
• Argumente: <id> (exakte Stelligkeit — zu viele sind ebenfalls ein Bedienfehler)
• Body: keiner

casa zeit korrigieren

Korrigiert einen EIGENEN, beendeten Eintrag (Positional <id>). Mindestens eines von --minuten <1 bis 1440>, --datum JJJJ-MM-TT, --art <Tätigkeitsart>, --notiz "<Text>". Ein laufender Timer ist nicht korrigierbar (erst stoppen), ein stornierter Eintrag nie.

casa zeit korrigieren <id> [--minuten <wert>] [--datum <wert>] [--art <wert>] [--notiz <wert>] --data '<json>'

• Endpunkt: PATCH /api/zeit/{id}
• Token nötig: ja
• Argumente: <id> (exakte Stelligkeit — zu viele sind ebenfalls ein Bedienfehler)
• Body-Flags: --minuten → Body-Feld dauerMinuten, --datum → Body-Feld leistungsdatum, --art → Body-Feld taetigkeitsart, --notiz → Body-Feld notiz
• Body: Pflicht (--data '<json>')

casa zeit stornieren

Storniert einen EIGENEN Eintrag (Positional <id>); er bleibt in casa zeit list auffindbar, zählt aber nirgends mehr. Pflicht: --grund "<Text>".

casa zeit stornieren <id> [--grund <wert>] --data '<json>'

• Endpunkt: POST /api/zeit/{id}/storno
• Token nötig: ja
• Argumente: <id> (exakte Stelligkeit — zu viele sind ebenfalls ein Bedienfehler)
• Body-Flags: --grund → Body-Feld grund
• Body: Pflicht (--data '<json>')

casa zeit list

Listet die EIGENEN Zeiteinträge im Zeitraum (nach Leistungsdatum), neueste zuerst, einschließlich stornierter. Optional --objekt <uuid> --von JJJJ-MM-TT --bis JJJJ-MM-TT (beide inklusiv); ohne Zeitraum der laufende Kalendermonat. Die Zeit anderer Mitarbeiter sieht dieses Kommando nie.

casa zeit list [--objekt <wert>] [--von <wert>] [--bis <wert>]

• Endpunkt: GET /api/zeit
• Token nötig: ja
• Query-Flags: --objekt, --von, --bis
• Body: keiner

casa zeit laufend

Listet die laufenden Timer des Angemeldeten (mehrere sind erlaubt), ältester zuerst. Nur die eigenen.

casa zeit laufend

• Endpunkt: GET /api/zeit/laufend
• Token nötig: ja
• Body: keiner

inbox

casa inbox list

Listet die Freigabe-Inbox (wartende Buchungsvorschläge des Tenants).

casa inbox list

• Endpunkt: GET /api/posteingang
• Token nötig: ja
• Body: keiner

ausnahmen

casa ausnahmen list

Listet die Ausnahme-Inbox (offene Verarbeitungs-/Routing-Ausnahmen des Tenants).

casa ausnahmen list

• Endpunkt: GET /api/ausnahmen
• Token nötig: ja
• Body: keiner

buchung

casa buchung ausfuehren

Führt einen freigegebenen Buchungsvorschlag aus. Braucht --data '{"proposalId":"<uuid>","proposalVersion":1,"entryKey":"<key>"}'. Optional "bookingDate":"YYYY-MM-DD" — rückdatiert die Ausführung; Betrag und Konto stammen aus der Freigabe, nie aus der Eingabe.

casa buchung ausfuehren --data '<json>'

• Endpunkt: POST /api/buchung
• Token nötig: ja
• Body: Pflicht (--data '<json>')

casa buchung eroeffnungsbestand

Migrationsnaht: baut Anfangsbestände auf (entry_type eroeffnung, beleglos, ohne Freigabe). Braucht --data '{"propertyId":"<uuid>","uebernahmestichtag":"YYYY-MM-DD","rueckstaende":[…]}'. Beträge als Integer-STRING in Cent. Idempotent je Übernahmestichtag + sourceKey.

casa buchung eroeffnungsbestand --data '<json>'

• Endpunkt: POST /api/buchung/eroeffnungsbestand
• Token nötig: ja
• Body: Pflicht (--data '<json>')

uebernahme

casa uebernahme abrechnung

Übernimmt die festgeschriebene Abrechnung EINES früheren Zeitraums eines Objekts als Bestand (kein Rechnen, kein Versand, kein Step-up). Pflicht: --datei <pfad> (lokale .json-Datei, höchstens 1 MiB) mit propertyId, periodFrom, periodTo, abrechnungsdatum, uebernahmestichtag und "vertraege" (je Vertrag contractId, vorauszahlungCents, anteilCents, ergebnisCents = Anteil − Vorauszahlung, kennzeichen verbucht\|offen; bei offener Nachzahlung faelligkeitNachzahlung, bei offenem Ergebnis im Objekt "eroeffnung" {ertragKontoNr, forderungsart, geldkreis, ustSatzProzent}). Beträge als Integer-STRING in Cent. Die Datei enthält keine Personendaten außer der Vertrags-Id. Das Personenkonto des Vertrags löst der Server aus der Vertrags-Id auf (kein Personenkonto ⇒ 409); alle Datumsfelder müssen echte Kalenderdaten sein (JJJJ-MM-TT, Zeitraum von ≤ bis). Optional --pruefen: validiert und zeigt die Vorschau (Summen, geplante Eröffnungsposten, Siegel) OHNE etwas zu schreiben — dieselben 404/409-Prüfungen wie beim Übernehmen. Offene Nachzahlungen werden über die Migrationsnaht als Eröffnungs-Sollstellung mit Originalfälligkeit gebucht, offene Guthaben als Eröffnungs-Gutschrift; "verbucht" erzeugt keinen offenen Posten. Der Zeitraum muss VOR dem Übernahmestichtag enden, und für Objekt und Zeitraum darf es noch keinen Lauf geben (sonst 409 mit Klartext; ein zweiter Aufruf ohne --idempotency-key ebenfalls). Mit demselben --idempotency-key ist die Wiederholung ein Replay ohne zweite Zeile. Fremdes oder unbekanntes Objekt bzw. fremder Vertrag ⇒ 404. Eine übernommene Abrechnung kennt weder § 35a-Bescheinigung noch Einwand (409).

casa uebernahme abrechnung [--pruefen] --datei <pfad> [--idempotency-key <key>]

• Endpunkt: POST /api/uebernahme/abrechnungen
• Token nötig: ja
• Body-Flags: --pruefen → Body-Feld pruefen
• Body: Pflicht (--datei <pfad>)

casa uebernahme abrechnungen

Listet die Abrechnungsläufe eines Objekts, neueste zuerst: je Lauf Zeitraum, Status, "herkunft" (uebernahme = als Bestand übernommen, sonst leer) und "uebernommen" (true/false). Braucht --propertyId <uuid>. Ein fremdes oder unbekanntes Objekt liefert eine leere Liste. Nur lesend.

casa uebernahme abrechnungen [--propertyId <wert>]

• Endpunkt: GET /api/uebernahme/abrechnungen
• Token nötig: ja
• Query-Flags: --propertyId
• Body: keiner

abrechnung

casa abrechnung starten

Startet einen Betriebskosten-Abrechnungslauf. Braucht --data '{"propertyId":"<uuid>","periodFrom":"YYYY-MM-DD","periodTo":"YYYY-MM-DD"}'. Optional "unitGroupId" (Abrechnungskreis). Blockierende Readiness-Befunde lehnen den Start ab (fail-closed).

casa abrechnung starten --data '<json>'

• Endpunkt: POST /api/abrechnung
• Token nötig: ja
• Body: Pflicht (--data '<json>')

casa abrechnung berechnet

Setzt den Abrechnungslauf auf "berechnet" (nur bei freigabefähigem Prüfbericht). Kein --data — die Lauf-id steht im Pfad.

casa abrechnung berechnet <id>

• Endpunkt: POST /api/abrechnung/{id}/berechnet
• Token nötig: ja
• Argumente: <id> (exakte Stelligkeit — zu viele sind ebenfalls ein Bedienfehler)
• Body: keiner

casa abrechnung ergebnis

Liest die Ergebniszahlen eines Abrechnungslaufs maschinenlesbar (Umlage-Zeilen + VZ-Gegenrechnung). Geld ausschließlich als Integer-STRING in Cent — nie als JSON-Zahl, nie gerundet.

casa abrechnung ergebnis <id>

• Endpunkt: GET /api/abrechnung/{id}
• Token nötig: ja
• Argumente: <id> (exakte Stelligkeit — zu viele sind ebenfalls ein Bedienfehler)
• Body: keiner

casa abrechnung s35a-bescheinigungen

Erzeugt die §35a-Bescheinigungen ALLER Wohnraum-Mieter eines FESTGESCHRIEBENEN Abrechnungslaufs in einem Lauf (Serienlauf je Objekt): je Vertrag Nutzungszeitraum, Einheiten und je §35a-Kategorie (beschaeftigungsverhaeltnis/haushaltsnah/handwerker) der Arbeits-/Lohnkostenanteil — bei Bewohnerwechsel zeitanteilig, Mehrfachbuchungen summiert, dieselbe Zahl wie im §35a-Ausweis der Abrechnung. summeBescheinigungen + summeNichtBescheinigt = summeS35aKosten (cent-genau). Geld ausschließlich als Integer-STRING in Cent. Das PDF (eine Seite je Bescheinigung) liefert GET /api/abrechnung/{id}/s35a-bescheinigungen?format=pdf.

casa abrechnung s35a-bescheinigungen <id>

• Endpunkt: GET /api/abrechnung/{id}/s35a-bescheinigungen
• Token nötig: ja
• Argumente: <id> (exakte Stelligkeit — zu viele sind ebenfalls ein Bedienfehler)
• Body: keiner

offene-posten

casa offene-posten list

Liest die offenen Posten samt der drei getrennten Summen (Rückstand · Guthaben · Saldo). Filter: --propertyId --contractId --geldkreis --menge offen\|alle --richtung forderung\|guthaben\|verbindlichkeit --dueFrom --dueTo --stichtag --archiveScope --asOf. Geld ausschließlich als Integer-STRING in Cent.

casa offene-posten list [--propertyId <wert>] [--contractId <wert>] [--geldkreis <wert>] [--menge <wert>] [--richtung <wert>] [--dueFrom <wert>] [--dueTo <wert>] [--stichtag <wert>] [--archiveScope <wert>] [--asOf <wert>]

• Endpunkt: GET /api/offene-posten
• Token nötig: ja
• Query-Flags: --propertyId, --contractId, --geldkreis, --menge, --richtung, --dueFrom, --dueTo, --stichtag, --archiveScope, --asOf
• Body: keiner

bankabgleich

casa bankabgleich vorlegen

Legt EINEN Bankumsatz als Buchungsvorschlag vor (ohne Freigabe, ohne Buchung). Braucht --data '{"bankAccountId":"<uuid>","bankTransactionId":"<uuid>","asOf":"YYYY-MM-DD"}'. Das Bankkonto (Soll) wird seit #1519 aus der Bankverbindung abgeleitet; ein trotzdem gesetztes "bankGlAccountNo" wird gegengeprüft und bei Abweichung abgewiesen. Optional "receivableGlAccountNo" und "contractId" (Vollkontierung). Die Antwort trägt die AMPEL — sie entscheidet über den Freigabeweg. Gibt der Kontenplan das Bank-Sachkonto nicht her (keine oder mehrere Zuordnungen am Objekt) oder weicht ein mitgeschicktes "bankGlAccountNo" ab, antwortet der Endpunkt mit 409 (seit #1860 kein 500 mehr): die CLI meldet dann error.code "conflict" bei Exit 1 — deterministisch, ein Retry hilft nicht, verzweige am Code. Ist die Bankverbindung nicht auflösbar (unbekannt, fremd oder archiviert), ist es "not_found" bei Exit 5. Den ausformulierten Klärungsweg trägt nur die HTTP-Antwort; die CLI druckt ihren eigenen Festtext, nicht die Server-Meldung.

casa bankabgleich vorlegen --data '<json>'

• Endpunkt: POST /api/bankabgleich/vorlegen
• Token nötig: ja
• Body: Pflicht (--data '<json>')

casa bankabgleich verbuchen

Legt vor, gibt frei und bucht. Braucht --data mit "modus". modus="einzeln" + "kontierung" fährt die Einzel-Freigabe (gelb erlaubt, rot blockiert); modus="sammel" + "kontierungen" (1..200) fährt die Sammel-Freigabe (ALL-GREEN — ein nicht-grüner Vorschlag lässt den ganzen Aufruf scheitern, bevor etwas gebucht wird). Dazu "bankAccountId" und "asOf". Dieselben Konto-Ablehnungen wie bei "vorlegen" enden auch hier mit 409 statt mit einem Serverfehler (seit #1860): error.code "conflict" bei Exit 1, bzw. "not_found" bei Exit 5, wenn die Bankverbindung nicht auflösbar ist. Auch hier steht der ausformulierte Klärungsweg nur in der HTTP-Antwort — die CLI druckt ihren lokalen Festtext.

casa bankabgleich verbuchen --data '<json>'

• Endpunkt: POST /api/bankabgleich/verbuchen
• Token nötig: ja
• Body: Pflicht (--data '<json>')

sollstellung

casa sollstellung starten

Startet einen Sollstellungslauf. Braucht --data '{"propertyId":"<uuid>","stichtag":"YYYY-MM-DD"}'. Offene Readiness-Befunde blockieren den Start; sie lassen sich mit "uebergehen":{"begruendung":"…"} auditiert übergehen. Ergebnis sind VORSCHLÄGE — gebucht wird erst nach der Freigabe.

casa sollstellung starten --data '<json>'

• Endpunkt: POST /api/sollstellung
• Token nötig: ja
• Body: Pflicht (--data '<json>')

casa sollstellung freigeben

Gibt die Vorschläge eines Sollstellungslaufs in EINEM Zug frei. Braucht --data '{"proposalIds":["<uuid>",…]}'. ALL-GREEN: ein einziger nicht-grüner Vorschlag lässt den ganzen Aufruf scheitern, es wird nichts freigegeben. Keine Teil-Freigabe.

casa sollstellung freigeben --data '<json>'

• Endpunkt: POST /api/sollstellung/freigabe
• Token nötig: ja
• Body: Pflicht (--data '<json>')

casa sollstellung vorschlaege

Liest die Vorschläge EINES Sollstellungslaufs — die Quelle der "proposalIds" für sollstellung freigeben. Filter: --art neu\|storno\|ersatz, --nurOffene true\|false (nur Vorschläge ohne bindende Entscheidung). Die Reihenfolge ist die kanonische STORNO VOR ERSATZ; betragCents ist ein Integer-STRING in Cent. Unbekannter oder fremder Lauf ⇒ error.code "not_found" bei Exit 5 (kein Existenz-Orakel).

casa sollstellung vorschlaege <id> [--art <wert>] [--nurOffene <wert>]

• Endpunkt: GET /api/sollstellung/{id}/vorschlaege
• Token nötig: ja
• Argumente: <id> (exakte Stelligkeit — zu viele sind ebenfalls ein Bedienfehler)
• Query-Flags: --art, --nurOffene
• Body: keiner

bank

casa bank umsaetze

Liest die IMPORTIERTEN Umsätze einer Bankverbindung — die Quelle der "bankTransactionId" für bankabgleich vorlegen/verbuchen. Filter: --menge alle\|offen\|gebucht (Default alle: das ist die Auskunft über den IMPORT, nicht die Arbeitsliste), --providerId (die eindeutige Bank-Referenz des Auszugs, bei camt AcctSvcrRef), --correlationId (EIN Import-Lauf), --buchungVon --buchungBis, --limit 1..200 (Default 50; "abgeschnitten" sagt, ob mehr da war). betragCents ist ein SIGNIERTER Integer-STRING in Cent (> 0 Eingang). Unbekannte oder fremde Bankverbindung ⇒ error.code "not_found" bei Exit 5. ACHTUNG: die Antwort trägt personenbezogene Daten (Verwendungszweck, Gegenkonto-IBAN, Kontoinhaber) — sie ist der Auszug, nicht eine Kennungsliste.

casa bank umsaetze <id> [--menge <wert>] [--providerId <wert>] [--correlationId <wert>] [--buchungVon <wert>] [--buchungBis <wert>] [--limit <wert>]

• Endpunkt: GET /api/bank/{id}/umsaetze
• Token nötig: ja
• Argumente: <id> (exakte Stelligkeit — zu viele sind ebenfalls ein Bedienfehler)
• Query-Flags: --menge, --providerId, --correlationId, --buchungVon, --buchungBis, --limit
• Body: keiner

casa bank list

Listet Bankverbindungen. --status alle\|aktiv\|archiviert (Default aktiv), --propertyId <uuid> grenzt auf ein Objekt ein.

casa bank list [--status <wert>] [--propertyId <wert>]

• Endpunkt: GET /api/bank
• Token nötig: ja
• Query-Flags: --status, --propertyId
• Body: keiner

casa bank get

Liest EINE Bankverbindung.

casa bank get <id>

• Endpunkt: GET /api/bank/{id}
• Token nötig: ja
• Argumente: <id> (exakte Stelligkeit — zu viele sind ebenfalls ein Bedienfehler)
• Body: keiner

casa bank create

Legt eine Bankverbindung an (propertyId, iban, kind). Braucht --data <json>.

casa bank create --data '<json>'

• Endpunkt: POST /api/bank
• Token nötig: ja
• Body: Pflicht (--data '<json>')

casa bank update

Ändert Bankverbindungs-Stammfelder (iban/kind/glaeubigerId). Braucht --data <json>.

casa bank update <id> --data '<json>'

• Endpunkt: PATCH /api/bank/{id}
• Token nötig: ja
• Argumente: <id> (exakte Stelligkeit — zu viele sind ebenfalls ein Bedienfehler)
• Body: Pflicht (--data '<json>')

casa bank archive

Archiviert eine Bankverbindung (archived_at statt Löschen).

casa bank archive <id>

• Endpunkt: POST /api/bank/{id}/archive
• Token nötig: ja
• Argumente: <id> (exakte Stelligkeit — zu viele sind ebenfalls ein Bedienfehler)
• Body: keiner

casa bank umsatz-import

Importiert einen Kontoauszug (Datei) auf eine Bankverbindung. --format camt.053\|camt.052\|mt940 wählt nur den Parser; verbucht wird das aus der Datei ERKANNTE Format. Die Datei wird serverseitig geparst; eine Wiederholung ist gefahrlos (Dedup).

casa bank umsatz-import <id> <datei> [--format <wert>]

• Endpunkt: POST /api/bank/{id}/umsatz-import
• Token nötig: ja
• Argumente: <id>, <datei> (exakte Stelligkeit — zu viele sind ebenfalls ein Bedienfehler)
• Query-Flags: --format
• Body: keiner

objekt

casa objekt list

Listet Objekte. --status alle\|aktiv\|archiviert (Default aktiv).

casa objekt list [--status <wert>]

• Endpunkt: GET /api/objekt
• Token nötig: ja
• Query-Flags: --status
• Body: keiner

casa objekt get

Liest EIN Objekt samt Buchungskreis.

casa objekt get <id>

• Endpunkt: GET /api/objekt/{id}
• Token nötig: ja
• Argumente: <id> (exakte Stelligkeit — zu viele sind ebenfalls ein Bedienfehler)
• Body: keiner

casa objekt check

Plausi-Gate: prüft die Objekt-Gesundheit (Ampel + Befunde als JSON). --asOf <YYYY-MM-DD> (Default heute).

casa objekt check <id> [--asOf <wert>]

• Endpunkt: GET /api/objekt/{id}/check
• Token nötig: ja
• Argumente: <id> (exakte Stelligkeit — zu viele sind ebenfalls ein Bedienfehler)
• Query-Flags: --asOf
• Body: keiner

casa objekt create

Legt ein Objekt an (Buchungskreis entsteht automatisch). Braucht --data <json>.

casa objekt create --data '<json>'

• Endpunkt: POST /api/objekt
• Token nötig: ja
• Body: Pflicht (--data '<json>')

casa objekt update

Ändert Objekt-Stammfelder. Braucht --data <json>.

casa objekt update <id> --data '<json>'

• Endpunkt: PATCH /api/objekt/{id}
• Token nötig: ja
• Argumente: <id> (exakte Stelligkeit — zu viele sind ebenfalls ein Bedienfehler)
• Body: Pflicht (--data '<json>')

casa objekt archive

Archiviert Objekt + Buchungskreis (archived_at statt Löschen).

casa objekt archive <id>

• Endpunkt: POST /api/objekt/{id}/archive
• Token nötig: ja
• Argumente: <id> (exakte Stelligkeit — zu viele sind ebenfalls ein Bedienfehler)
• Body: keiner

casa objekt eigentum list

Liest das Eigentum eines Objekts zum Stichtag, je Einheit, mit Anteilssumme und Befund "anteilssumme_ungleich_10000". Pflicht: --stichtag <YYYY-MM-DD> (keine Server-Uhr). Optional --einheit <uuid> (nur diese Einheit) und --historie 1 (auch abgelaufene und künftige Zeilen; "istGegenwart" markiert die am Stichtag wirksamen). Anteile in Zehntausendsteln. Die Zustellanschrift steht nie in der Antwort, nur "hatZustellanweisung". Fremdes oder unbekanntes Objekt bzw. Einheit ist not_found.

casa objekt eigentum list <id> [--stichtag <wert>] [--einheit <wert>] [--historie <wert>]

• Endpunkt: GET /api/objekt/{id}/eigentum
• Token nötig: ja
• Argumente: <id> (exakte Stelligkeit — zu viele sind ebenfalls ein Bedienfehler)
• Query-Flags: --stichtag, --einheit, --historie
• Body: keiner

casa objekt beschluss list

Liest die Beschluss-Sammlung eines Objekts (§ 24 Abs. 7 WEG). OHNE --status: die VOLLSTÄNDIGE Sammlung. --status <a,b,…> filtert (angenommen, abgelehnt, angefochten, bestandskraeftig, aufgehoben, nichtig); ein unbekannter Wert ist ein Fehler, keine leere Liste.

casa objekt beschluss list <id> [--status <wert>]

• Endpunkt: GET /api/objekt/{id}/beschluss
• Token nötig: ja
• Argumente: <id> (exakte Stelligkeit — zu viele sind ebenfalls ein Bedienfehler)
• Query-Flags: --status
• Body: keiner

casa objekt beschluss erfassen

Erfasst EINEN Beschluss samt Teil-Gegenständen — auch der Weg des WinCASA-Alt-Imports. --data '{"lfdNr":14,"thema":"…","quelle":"alt_import","gegenstaende":[{"lfdNr":1,"bezeichnung":"…","wpGegenstaende":["vorschuesse","ruecklagenzufuehrung"],"wpFortgeltung":true}]}'. wpGegenstaende/wpFortgeltung (nur mit vorschuesse) machen den Teil zum Träger eines Wirtschaftsplans. Ein Änderungs-Kommando gibt es bewusst nicht: Korrektur ist ein Zweitbeschluss.

casa objekt beschluss erfassen <id> --data '<json>'

• Endpunkt: POST /api/objekt/{id}/beschluss
• Token nötig: ja
• Argumente: <id> (exakte Stelligkeit — zu viele sind ebenfalls ein Bedienfehler)
• Body: Pflicht (--data '<json>')

casa objekt beschluss import

Importiert einen WinCASA-Beschlussbestand in die Sammlung eines Objekts (Export der Tabelle VERTHEMEN bzw. VERSAMMLUNG_ERG, serverseitig geparst). Braucht --onr <objektnummer-im-altbestand>. Der Bericht nennt die BEFUNDE je Zeile — u. a. wenn die überlieferten Zählwerte dem übernommenen Status widersprechen; dieselben Befunde stehen dauerhaft im Import-Vermerk des Beschlusses. Teilerfolg ist erlaubt: abgewiesene Zeilen stehen benannt im Bericht. Ein zweiter Lauf derselben Datei legt nichts doppelt an — nicht durch Idempotenz (der CLI-Lauf prägt je Aufruf einen frischen Schlüssel), sondern weil die laufende Nummer je Objekt eindeutig ist; die bereits importierten Zeilen erscheinen dann unter „fehlgeschlagen".

casa objekt beschluss import <id> <datei> [--onr <wert>]

• Endpunkt: POST /api/objekt/{id}/beschluss/import
• Token nötig: ja
• Argumente: <id>, <datei> (exakte Stelligkeit — zu viele sind ebenfalls ein Bedienfehler)
• Query-Flags: --onr
• Body: keiner

casa objekt versammlung list

Liest die Versammlungen (und Umlaufbeschlüsse) eines Objekts, jüngstes Versammlungsdatum zuerst. Beim Umlaufbeschluss werden Stimmprinzip und Beschlussfähigkeit nicht ausgewiesen.

casa objekt versammlung list <id>

• Endpunkt: GET /api/objekt/{id}/versammlung
• Token nötig: ja
• Argumente: <id> (exakte Stelligkeit — zu viele sind ebenfalls ein Bedienfehler)
• Body: keiner

casa objekt versammlung anlegen

Legt eine Versammlung (--art ordentlich \| ausserordentlich) oder einen Umlaufbeschluss (--art umlauf) für ein Objekt an. --datum <YYYY-MM-DD> ist das Versammlungsdatum (beim Umlaufbeschluss das Datum der Beschlussfassung), --einladung <YYYY-MM-DD> das Einladungsdatum, --begruendung <text> die Begründung einer verkürzten Einladungsfrist, --stimmprinzip koepfe (Default) \| mea \| objekt; weitere Felder per --data (beschlussfaehig, beschlussfaehigkeitNotiz). Liegt die Einladung weniger als 3 Wochen (21 Tage) vor der Versammlung, gibt es eine Warnung (Feld hinweise) und die Begründung ist Pflicht — aber keine Sperre: mit Begründung wird gespeichert. Ohne Einladungsdatum wird gespeichert, Hinweis einladung-nicht-erfasst. Der Umlaufbeschluss ist nur eine Art: kein Einladungsdatum, keine Teilnehmer, kein Stimmprinzip; die Abstimmung läuft nicht über casa.ai.

casa objekt versammlung anlegen <id> [--art <wert>] [--datum <wert>] [--einladung <wert>] [--begruendung <wert>] [--stimmprinzip <wert>] --data '<json>'

• Endpunkt: POST /api/objekt/{id}/versammlung
• Token nötig: ja
• Argumente: <id> (exakte Stelligkeit — zu viele sind ebenfalls ein Bedienfehler)
• Body-Flags: --art → Body-Feld art, --datum → Body-Feld versammlungsdatum, --einladung → Body-Feld einladungsdatum, --begruendung → Body-Feld einladungsfristBegruendung, --stimmprinzip → Body-Feld stimmprinzip
• Body: Pflicht (--data '<json>')

casa objekt brennstoffkonto show

Liest das Brennstoffkonto eines Objekts: <objektId>. Zeigt das aktive Konto (Kontonummer, Name, Zustand, gesetztAm), den gemerkten Ausgangszustand (vorzustand), den Befund (brennstoffkonto-verteilt-doppelt, wenn das Brennstoffkonto trotzdem umlagefähig ist oder einen Umlageschlüssel trägt) und die Konten des Objekts mit Heizkosten-Kostenart (heizkostenKonten) als Auswahlhilfe für setzen. Das Brennstoffkonto verteilt die Heizkosten über die Heizkostenabrechnung und darf nicht zusätzlich als Betriebskosten umgelegt werden (sonst stehen die Heizkosten doppelt in der Abrechnung). Nur lesend.

casa objekt brennstoffkonto show <id>

• Endpunkt: GET /api/objekt/{id}/brennstoffkonto
• Token nötig: ja
• Argumente: <id> (exakte Stelligkeit — zu viele sind ebenfalls ein Bedienfehler)
• Body: keiner

casa objekt brennstoffkonto setzen

Setzt oder wechselt das Brennstoffkonto eines Objekts: <objektId> --konto <glAccountId> (Pflicht; Auswahlhilfe: casa objekt brennstoffkonto show) und --bestaetigt (Schalter ohne Wert). Das Brennstoffkonto verteilt die Heizkosten über die Heizkostenabrechnung und darf nicht zusätzlich als Betriebskosten umgelegt werden (sonst stehen die Heizkosten doppelt in der Abrechnung). Setzen macht das Konto nicht umlagefähig und entfernt den Umlageschlüssel, deshalb ist --bestaetigt immer Pflicht (ohne die Flagge fehlt bestaetigt im Body: 400 mit Klartext, was verloren geht, nichts geschrieben; --bestaetigt=false ist erlaubt und bestätigt nicht, ein umlagefähiges Konto wird dann abgelehnt). Das frühere Brennstoffkonto geht auf seinen gespeicherten Ausgangszustand zurück. Ein Konto mit Buchungen wird nicht umgestellt (409 konto-gebucht); dasselbe Konto zweimal ⇒ 409 bereits-brennstoffkonto. Ein Agent darf nicht (403). Mit --idempotency-key wiederholungssicher.

casa objekt brennstoffkonto setzen <id> [--konto <wert>] [--bestaetigt] --data '<json>'

• Endpunkt: POST /api/objekt/{id}/brennstoffkonto
• Token nötig: ja
• Argumente: <id> (exakte Stelligkeit — zu viele sind ebenfalls ein Bedienfehler)
• Body-Flags: --konto → Body-Feld glAccountId, --bestaetigt → Body-Feld bestaetigt
• Body: Pflicht (--data '<json>')

casa objekt brennstoffkonto aufheben

Hebt das Brennstoffkonto eines Objekts auf: <objektId> und --bestaetigt (Schalter ohne Wert). Die Markierung endet, das Konto geht auf seinen gespeicherten Ausgangszustand zurück. --bestaetigt ist immer Pflicht (ohne die Flagge fehlt bestaetigt im Body: 400 mit Klartext, nichts geschrieben; wird das Konto dadurch wieder umlagefähig oder erhält es einen Umlageschlüssel, laufen seine Kosten wieder in die Betriebskostenumlage). Ein inzwischen gebuchtes Konto bleibt wie es ist (Hinweis in der Antwort). Hat das Objekt kein Brennstoffkonto ⇒ 404. Ein Agent darf nicht (403).

casa objekt brennstoffkonto aufheben <id> [--bestaetigt] --data '<json>'

• Endpunkt: POST /api/objekt/{id}/brennstoffkonto/aufheben
• Token nötig: ja
• Argumente: <id> (exakte Stelligkeit — zu viele sind ebenfalls ein Bedienfehler)
• Body-Flags: --bestaetigt → Body-Feld bestaetigt
• Body: Pflicht (--data '<json>')

casa objekt abschluss list

Liest die Abschluss-Läufe eines Objekts. --jahr <wirtschaftsjahr> filtert; ein Jahr ohne Lauf ergibt eine LEERE Liste, keinen Fehler. Stornierte Läufe verschwinden NICHT aus dem Bestand (GoBD) — sie tragen storniert: true.

casa objekt abschluss list <id> [--jahr <wert>]

• Endpunkt: GET /api/objekt/{id}/abschluss
• Token nötig: ja
• Argumente: <id> (exakte Stelligkeit — zu viele sind ebenfalls ein Bedienfehler)
• Query-Flags: --jahr
• Body: keiner

casa objekt abschluss korrektur

Führt die Korrektur-Kette einer Kaskaden-Neuberechnung aus: je betroffenem Jahr ein Storno und ein NEUER Lauf mit Referenz auf den stornierten. --data '{"jahr":2024,"schluessel":"weg-abschluss-korrektur\|…"}'. Der Idempotenz-Schlüssel kommt vom Aufrufer — zwei Aufrufe am selben Schlüssel ergeben GENAU EINEN neuen Lauf.

casa objekt abschluss korrektur <id> --data '<json>'

• Endpunkt: POST /api/objekt/{id}/abschluss/korrektur
• Token nötig: ja
• Argumente: <id> (exakte Stelligkeit — zu viele sind ebenfalls ein Bedienfehler)
• Body: Pflicht (--data '<json>')

casa objekt buchungsperioden

Zeigt Stand und Protokoll der festschreibbaren Buchungsperioden eines Objekts: "aktiv" (Schalter des Objekts, sonst Vorgabe des Mandanten, sonst aus), "wirtschaftsjahrBeginn" ("kalenderjahr" oder "abweichend_MM-DD"), je Festschreibung "von"/"bis" und Status "geltend" (gesperrt) oder "geoeffnet" (mit Grund, wer, wann) und im "protokoll" je Öffnung die Journalsätze, die zwischen Öffnung und Neu-Festschreiben mit Datum in der Periode gebucht wurden (Storno- und Ergänzungsbuchungen; offene Posten und Sollstellungen stehen nicht darin). Bei ausgeschaltetem Schalter bleibt eine festgeschriebene Periode gesperrt und steht als "geltend" da. --format export liefert dieselben Daten als deterministische Export-Datei (gleiche Daten ergeben gleiche Bytes, ohne Erzeugungszeit; Ersatz für das PDF zur Vorlage bei den Finanzbehörden). ACHTUNG: der Öffnungsgrund ist Freitext (personenbezogen möglich). Unbekanntes, fremdes oder nicht zuständiges Objekt ⇒ 404.

casa objekt buchungsperioden <id> [--format <wert>]

• Endpunkt: GET /api/objekt/{id}/buchungsperioden
• Token nötig: ja
• Argumente: <id> (exakte Stelligkeit — zu viele sind ebenfalls ein Bedienfehler)
• Query-Flags: --format
• Body: keiner

casa objekt festschreiben

Schreibt die nächste Buchungsperiode eines Objekts fest (Wirtschaftsjahr des Objekts, lückenlos) oder schreibt eine geöffnete Periode neu fest. Braucht --data '{}'; bei der ERSTEN Festschreibung --data '{"von":"2025-01-01"}' (Beginn eines Wirtschaftsjahres), bei einer geöffneten Periode ihr Beginn als "von". Nur ein Mensch; der Schalter des Objekts muss an sein ("einstellungen festschreibung"). Gesperrt, Lücke, kein Jahresbeginn, Wirtschaftsjahr unklar ⇒ 409 mit Code (PERIODE_FESTGESCHRIEBEN, FESTSCHREIBUNG_LUECKE, FESTSCHREIBUNG_KEIN_JAHRESBEGINN, WIRTSCHAFTSJAHR_UNKLAR); fremdes Objekt ⇒ 404; Agent ⇒ 403. Wiederholungssicher mit --idempotency-key.

casa objekt festschreiben <id> --data '<json>'

• Endpunkt: POST /api/objekt/{id}/buchungsperioden/festschreibung
• Token nötig: ja
• Argumente: <id> (exakte Stelligkeit — zu viele sind ebenfalls ein Bedienfehler)
• Body: Pflicht (--data '<json>')

casa objekt oeffnen

Öffnet eine festgeschriebene Buchungsperiode eines Objekts mit Pflichtgrund (auch eine mittlere): --data '{"festschreibungId":"<uuid>","grund":"Nachtrag Beleg"}' (die Id steht in "objekt buchungsperioden"). Der Grund ist Pflicht (nicht leer) und wird mit Person und Zeitpunkt unveränderlich protokolliert; er ist Freitext (personenbezogen möglich). Danach sind Storno- und Ergänzungsbuchungen mit Datum in der Periode möglich, bis sie neu festgeschrieben wird ("objekt festschreiben"). Schon geöffnet ⇒ 409; fremd oder nicht zum Objekt gehörig ⇒ 404; Agent ⇒ 403. Wiederholungssicher mit --idempotency-key.

casa objekt oeffnen <id> --data '<json>'

• Endpunkt: POST /api/objekt/{id}/buchungsperioden/oeffnung
• Token nötig: ja
• Argumente: <id> (exakte Stelligkeit — zu viele sind ebenfalls ein Bedienfehler)
• Body: Pflicht (--data '<json>')

casa objekt vermoegensbericht list

Liest die abgelegten Vermögensberichts-Stände eines Objekts (§ 28 Abs. 4 WEG). --stichtag <YYYY-MM-DD> filtert; ein Objekt ohne Stand ergibt eine LEERE Liste, keinen Fehler. Ältere Stände verschwinden NICHT (GoBD) — sie tragen ihre standNr, der jüngste zuerst.

casa objekt vermoegensbericht list <id> [--stichtag <wert>]

• Endpunkt: GET /api/objekt/{id}/vermoegensbericht
• Token nötig: ja
• Argumente: <id> (exakte Stelligkeit — zu viele sind ebenfalls ein Bedienfehler)
• Query-Flags: --stichtag
• Body: keiner

casa objekt vermoegensbericht erstellen

Erzeugt den Vermögensbericht eines Objekts zum Stichtag und legt ihn als NEUEN Stand ab. --data '{"stichtag":"2024-12-31","schluessel":"vermoegensbericht\|…","auftrag":{…}}'. Der Idempotenz-Schlüssel kommt vom Aufrufer: zwei Aufrufe am selben Schlüssel ergeben GENAU EINEN Stand. Readiness- und Konsistenz-Befunde stehen in der Antwort — sie gehören zum Bericht.

casa objekt vermoegensbericht erstellen <id> [--stichtag <wert>] [--schluessel <wert>] --data '<json>'

• Endpunkt: POST /api/objekt/{id}/vermoegensbericht
• Token nötig: ja
• Argumente: <id> (exakte Stelligkeit — zu viele sind ebenfalls ein Bedienfehler)
• Body-Flags: --stichtag → Body-Feld stichtag, --schluessel → Body-Feld idempotenzSchluessel
• Body: Pflicht (--data '<json>')

casa objekt hausgeld list

Liest die Hausgeld-Sollstellungen eines Objekts (§ 28 Abs. 1 WEG). --jahr <wirtschaftsjahr> filtert; ein Jahr ohne Soll ergibt eine LEERE Liste, keinen Fehler. Vorschuss und rückwirkende Differenz stehen NEBENEINANDER — die Differenz ersetzt den Vorschuss nicht.

casa objekt hausgeld list <id> [--jahr <wert>]

• Endpunkt: GET /api/objekt/{id}/hausgeld
• Token nötig: ja
• Argumente: <id> (exakte Stelligkeit — zu viele sind ebenfalls ein Bedienfehler)
• Query-Flags: --jahr
• Body: keiner

casa objekt hausgeld soll

Stellt das Hausgeld eines Objekts für ein Wirtschaftsjahr fällig — je Einheit und Monat eine Sollstellung. --data '{"jahr":2024,"geldkreis":"weg_hausgeld","schluessel":"hausgeld-soll\|…",…}'. Der Idempotenz-Schlüssel kommt vom Aufrufer: zwei Läufe am selben Schlüssel stellen GENAU EINMAL Soll. Rückwirkende Differenzen liefert der Lauf als VORSCHLAG und bucht sie nicht.

casa objekt hausgeld soll <id> --data '<json>'

• Endpunkt: POST /api/objekt/{id}/hausgeld/soll
• Token nötig: ja
• Argumente: <id> (exakte Stelligkeit — zu viele sind ebenfalls ein Bedienfehler)
• Body: Pflicht (--data '<json>')

casa objekt hausgeld differenz

Quittiert rückwirkende Differenz-Vorschläge eines Soll-Laufs — der GEFÜHRTE Schritt. --von und --am sind Pflicht: ein anonymer Freigabeschritt ist keiner (GoBD), und der Tag kommt nicht aus der Uhr des Servers (BP §8). Die Vorschläge reisen so, wie der Lauf sie geliefert hat — Schuldner und Plan-Version werden nicht neu abgeleitet.

casa objekt hausgeld differenz <id> [--von <wert>] [--am <wert>] --data '<json>'

• Endpunkt: POST /api/objekt/{id}/hausgeld/differenz
• Token nötig: ja
• Argumente: <id> (exakte Stelligkeit — zu viele sind ebenfalls ein Bedienfehler)
• Body-Flags: --von → Body-Feld quittiertVon, --am → Body-Feld quittiertAm
• Body: Pflicht (--data '<json>')

casa objekt ruecklage list

Listet den Katalog der Rücklagen eines Objekts (älteste zuerst) mit Art, Bezeichnung, Zweckbindung, Konten, Kontoinhaber, Ist-Bestand und Kennzeichen "aufgeloest". --stichtag <YYYY-MM-DD> nennt den Tag des Ist-Bestands (inklusive); ohne ihn ist der Ist-Bestand null. Aufgelöste Rücklagen bleiben im Katalog. Geld ist ein Objekt {cents, currency}.

casa objekt ruecklage list <id> [--stichtag <wert>]

• Endpunkt: GET /api/objekt/{id}/ruecklagen
• Token nötig: ja
• Argumente: <id> (exakte Stelligkeit — zu viele sind ebenfalls ein Bedienfehler)
• Query-Flags: --stichtag
• Body: keiner

casa objekt ruecklage soll-ist

Liest Soll, Ist und Rückstand der Rücklagen eines Objekts zum Stichtag. Pflicht: --stichtag <YYYY-MM-DD> (inklusive). --ruecklageId <uuid> beschränkt auf eine Rücklage; ohne sie kommen alle Rücklagen des Objekts. Eine fremde oder unbekannte Rücklage ist not_found. Geld ist ein Objekt {cents, currency}.

casa objekt ruecklage soll-ist <id> [--stichtag <wert>] [--ruecklageId <wert>]

• Endpunkt: GET /api/objekt/{id}/ruecklagen/soll-ist
• Token nötig: ja
• Argumente: <id> (exakte Stelligkeit — zu viele sind ebenfalls ein Bedienfehler)
• Query-Flags: --stichtag, --ruecklageId
• Body: keiner

casa objekt ruecklage abstimmung

Stimmt das aktive Bestandskonto gegen das passive Rücklagenkonto ab, je Rücklage und gesamt, mit Befunden (fehlende Umbuchung Giro → Festgeld, Konto ohne Gegenstück). Pflicht: --stichtag <YYYY-MM-DD> (inklusive). Ein Konto, das mehrfach im Katalog steht, ist ein Konflikt. Geld ist ein Objekt {cents, currency}.

casa objekt ruecklage abstimmung <id> [--stichtag <wert>]

• Endpunkt: GET /api/objekt/{id}/ruecklagen/abstimmung
• Token nötig: ja
• Argumente: <id> (exakte Stelligkeit — zu viele sind ebenfalls ein Bedienfehler)
• Query-Flags: --stichtag
• Body: keiner

casa objekt ruecklage wiedervorlagen

Listet die offenen Zwischenfinanzierungen eines Objekts (noch nicht zurückgeführt) mit Fälligkeit, Frist, Betrag und Beschluss-Referenz, nach Fälligkeit geordnet. Pflicht: --bis <YYYY-MM-DD>: überfällig ist, was VOR diesem Tag fällig war (eine Auskunft, keine Sperre). Geld ist ein Objekt {cents, currency}.

casa objekt ruecklage wiedervorlagen <id> [--bis <wert>]

• Endpunkt: GET /api/objekt/{id}/ruecklagen/wiedervorlagen
• Token nötig: ja
• Argumente: <id> (exakte Stelligkeit — zu viele sind ebenfalls ein Bedienfehler)
• Query-Flags: --bis
• Body: keiner

casa objekt ruecklage anlegen

Legt eine Rücklage des Objekts samt Kontenpaar an (passives Rücklagenkonto, aktives Bestandskonto). --art erhaltung\|zweckgebunden, --bezeichnung, --kontoinhaberArt gdwe\|verwalter\|dritter, --kontoinhaberName sind Pflicht; --zweckbindung ist bei zweckgebunden Pflicht und bei erhaltung verboten; optional --verteilerschluessel, --unitGroupId, --aktivKontoId (ein bestehendes Bankkonto des Objekts). Die Erhaltungsrücklage gibt es je Objekt genau einmal.

casa objekt ruecklage anlegen <id> [--art <wert>] [--bezeichnung <wert>] [--zweckbindung <wert>] [--verteilerschluessel <wert>] [--unitGroupId <wert>] [--kontoinhaberArt <wert>] [--kontoinhaberName <wert>] [--aktivKontoId <wert>] --data '<json>'

• Endpunkt: POST /api/objekt/{id}/ruecklagen
• Token nötig: ja
• Argumente: <id> (exakte Stelligkeit — zu viele sind ebenfalls ein Bedienfehler)
• Body-Flags: --art → Body-Feld art, --bezeichnung → Body-Feld bezeichnung, --zweckbindung → Body-Feld zweckbindung, --verteilerschluessel → Body-Feld verteilerschluessel, --unitGroupId → Body-Feld unitGroupId, --kontoinhaberArt → Body-Feld kontoinhaberArt, --kontoinhaberName → Body-Feld kontoinhaberName, --aktivKontoId → Body-Feld aktivKontoId
• Body: Pflicht (--data '<json>')

casa objekt ruecklage soll

Legt die Soll-Zuführung einer Rücklage fest, gebunden an einen Beschluss-Teilgegenstand. Pflicht: --ruecklageId <uuid>, --betrag <Cent als Ziffern-String, > 0, z. B. 120000 = 1.200,00 €>, --beschluss <beschluss-gegenstand:uuid>, --datum <YYYY-MM-DD> (Fälligkeit). Ohne Beschluss-Referenz wird nichts gespeichert.

casa objekt ruecklage soll <id> [--ruecklageId <wert>] [--betrag <wert>] [--beschluss <wert>] [--datum <wert>] --data '<json>'

• Endpunkt: POST /api/objekt/{id}/ruecklagen/soll
• Token nötig: ja
• Argumente: <id> (exakte Stelligkeit — zu viele sind ebenfalls ein Bedienfehler)
• Body-Flags: --ruecklageId → Body-Feld ruecklageId, --betrag → Body-Feld betragCents, --beschluss → Body-Feld beschlussGegenstandRef, --datum → Body-Feld faelligZum
• Body: Pflicht (--data '<json>')

casa objekt ruecklage buchen

Bucht eine Bewegung auf dem passiven Rücklagenkonto. --betrag ist ein vorzeichenbehafteter Ziffern-String in CENT: 5000 = Zuführung von 50,00 €, --betrag -5000 = Entnahme von 50,00 €. Pflicht: --ruecklageId, --betrag, --datum <YYYY-MM-DD>, --gegenkonto <uuid>. Zuführung: optional --periode <YYYY-MM>, dieselbe Periode wird nur EINMAL gebucht (zweite Antwort ausgang bereits_gebucht, kein zweiter Journalsatz). Entnahme: --zweck wartung\|inspektion\|instandsetzung\|modernisierende_instandsetzung\|bauliche_veraenderung\|modernisierung ist Pflicht; bauliche_veraenderung und modernisierung brauchen --umwidmung <Umwidmungsbeschluss-Referenz>; optional --beschluss. Korrektur: Gegenbewegung mit umgekehrtem Vorzeichen und --korrigiert <bewegungId>.

casa objekt ruecklage buchen <id> [--ruecklageId <wert>] [--betrag <wert>] [--datum <wert>] [--gegenkonto <wert>] [--periode <wert>] [--zweck <wert>] [--beschluss <wert>] [--umwidmung <wert>] [--korrigiert <wert>] --data '<json>'

• Endpunkt: POST /api/objekt/{id}/ruecklagen/buchung
• Token nötig: ja
• Argumente: <id> (exakte Stelligkeit — zu viele sind ebenfalls ein Bedienfehler)
• Body-Flags: --ruecklageId → Body-Feld ruecklageId, --betrag → Body-Feld betragCents, --datum → Body-Feld buchungsdatum, --gegenkonto → Body-Feld gegenkontoId, --periode → Body-Feld periode, --zweck → Body-Feld zweck, --beschluss → Body-Feld beschlussGegenstandRef, --umwidmung → Body-Feld umwidmungsBeschlussRef, --korrigiert → Body-Feld korrigiertBewegungId
• Body: Pflicht (--data '<json>')

casa objekt ruecklage zins

Erfasst einen Zinsertrag einer Rücklage: brutto wird in Kapitalertragsteuer (25 %), Solidaritätszuschlag (5,5 % auf die Steuer) und netto aufgeteilt. Pflicht: --ruecklageId, --brutto <Cent als Ziffern-String, > 0>, --datum <YYYY-MM-DD>, --zinskonto <uuid>, --steuerkonto <uuid>. Ein negativer Zins (Verwahrentgelt) hat hier keinen Weg.

casa objekt ruecklage zins <id> [--ruecklageId <wert>] [--brutto <wert>] [--datum <wert>] [--zinskonto <wert>] [--steuerkonto <wert>] --data '<json>'

• Endpunkt: POST /api/objekt/{id}/ruecklagen/zins
• Token nötig: ja
• Argumente: <id> (exakte Stelligkeit — zu viele sind ebenfalls ein Bedienfehler)
• Body-Flags: --ruecklageId → Body-Feld ruecklageId, --brutto → Body-Feld bruttoCents, --datum → Body-Feld buchungsdatum, --zinskonto → Body-Feld zinsKontoId, --steuerkonto → Body-Feld steuerKontoId
• Body: Pflicht (--data '<json>')

casa objekt ruecklage zwischenfinanzierung

Entnimmt der Rücklage kurzfristig Liquidität gegen Beschluss und legt eine Wiedervorlage an. Pflicht: --ruecklageId, --betrag <Cent als POSITIVER Ziffern-String>, --datum <YYYY-MM-DD>, --beschluss <Beschluss-Referenz>. Optional --frist <Monate> (überschreibt die Policy-Frist, Vorgabe 3) und --gegenkonto <uuid> (sonst das Bestandskonto der Rücklage). Die Rückführung ist ein eigenes Kommando.

casa objekt ruecklage zwischenfinanzierung <id> [--ruecklageId <wert>] [--betrag <wert>] [--datum <wert>] [--beschluss <wert>] [--frist <wert>] [--gegenkonto <wert>] --data '<json>'

• Endpunkt: POST /api/objekt/{id}/ruecklagen/zwischenfinanzierung
• Token nötig: ja
• Argumente: <id> (exakte Stelligkeit — zu viele sind ebenfalls ein Bedienfehler)
• Body-Flags: --ruecklageId → Body-Feld ruecklageId, --betrag → Body-Feld betragCents, --datum → Body-Feld entnahmeDatum, --beschluss → Body-Feld beschlussRef, --frist → Body-Feld fristMonate, --gegenkonto → Body-Feld gegenkontoId
• Body: Pflicht (--data '<json>')

casa objekt ruecklage rueckfuehrung

Führt eine Zwischenfinanzierung in voller Höhe in die Rücklage zurück. Pflicht: --ruecklageId, --zwischenfinanzierung <bewegungId der Entnahme>, --datum <YYYY-MM-DD>, --gegenkonto <uuid>. Offene Zwischenfinanzierungen zeigt casa objekt ruecklage wiedervorlagen.

casa objekt ruecklage rueckfuehrung <id> [--ruecklageId <wert>] [--zwischenfinanzierung <wert>] [--datum <wert>] [--gegenkonto <wert>] --data '<json>'

• Endpunkt: POST /api/objekt/{id}/ruecklagen/rueckfuehrung
• Token nötig: ja
• Argumente: <id> (exakte Stelligkeit — zu viele sind ebenfalls ein Bedienfehler)
• Body-Flags: --ruecklageId → Body-Feld ruecklageId, --zwischenfinanzierung → Body-Feld zwischenfinanzierungBewegungId, --datum → Body-Feld buchungsdatum, --gegenkonto → Body-Feld gegenkontoId
• Body: Pflicht (--data '<json>')

casa objekt ruecklage aufloesen

Löst eine Rücklage auf — nur gegen Aufhebungsbeschluss und nur bei Saldo 0,00 €. Pflicht: --ruecklageId, --beschluss <Aufhebungsbeschluss-Referenz>, --datum <YYYY-MM-DD>. Die Rücklage bleibt im Katalog (aufgeloest true), danach wird nichts mehr auf sie gebucht.

casa objekt ruecklage aufloesen <id> [--ruecklageId <wert>] [--beschluss <wert>] [--datum <wert>] --data '<json>'

• Endpunkt: POST /api/objekt/{id}/ruecklagen/aufloesung
• Token nötig: ja
• Argumente: <id> (exakte Stelligkeit — zu viele sind ebenfalls ein Bedienfehler)
• Body-Flags: --ruecklageId → Body-Feld ruecklageId, --beschluss → Body-Feld aufhebungsBeschlussRef, --datum → Body-Feld aufgeloestAm
• Body: Pflicht (--data '<json>')

casa objekt sonderumlage list

Listet die Sonderumlagen eines Objekts (nach Fälligkeit) mit Zweck, Gesamtbetrag, Zahlweise, Raten-Fälligkeiten, Kennzeichen "gestellt" (Soll steht) und der Tatsache "schluesselAbweichung". Geld ist ein Objekt {cents, currency}.

casa objekt sonderumlage list <id>

• Endpunkt: GET /api/objekt/{id}/sonderumlage
• Token nötig: ja
• Argumente: <id> (exakte Stelligkeit — zu viele sind ebenfalls ein Bedienfehler)
• Body: keiner

casa objekt sonderumlage show

Zeigt das gestellte Soll EINER Sonderumlage je Einheit und Rate mit Schuldnern (Eigentümer am Fälligkeitstag, Anteil in Zehntausendsteln). Pflicht: --sonderumlageId <uuid>. Solange das Soll nicht gestellt ist, ist die Einheitenliste leer. Eine fremde oder unbekannte Sonderumlage ist not_found.

casa objekt sonderumlage show <id> [--sonderumlageId <wert>]

• Endpunkt: GET /api/objekt/{id}/sonderumlage/soll
• Token nötig: ja
• Argumente: <id> (exakte Stelligkeit — zu viele sind ebenfalls ein Bedienfehler)
• Query-Flags: --sonderumlageId
• Body: keiner

casa objekt sonderumlage anlegen

Legt eine Sonderumlage mit ihrem Sonderkonto an, gebunden an einen Beschluss-Teilgegenstand. Pflicht: --beschluss <beschluss-gegenstand:uuid>, --zweck <Text laut Beschluss>, --betrag <Gesamtbetrag in Cent als Ziffern-String, > 0, z. B. 1200000 = 12.000,00 €>, --faelligkeit <YYYY-MM-DD>, --zahlweise einmalzahlung\|raten. Bei raten zusätzlich --raten <YYYY-MM-DD,YYYY-MM-DD,…> (die erste Rate ist die Fälligkeit); bei einmalzahlung keine Raten. Optional --zufuehrungsSchluessel (Vorgabe mea), --entnahmeSchluessel, --abweichungsBeschluss. Ohne Beschluss, Zweck oder Fälligkeit wird nichts gespeichert.

casa objekt sonderumlage anlegen <id> [--beschluss <wert>] [--zweck <wert>] [--betrag <wert>] [--faelligkeit <wert>] [--zahlweise <wert>] [--raten <wert>] [--zufuehrungsSchluessel <wert>] [--entnahmeSchluessel <wert>] [--abweichungsBeschluss <wert>] --data '<json>'

• Endpunkt: POST /api/objekt/{id}/sonderumlage
• Token nötig: ja
• Argumente: <id> (exakte Stelligkeit — zu viele sind ebenfalls ein Bedienfehler)
• Body-Flags: --beschluss → Body-Feld beschlussGegenstandRef, --zweck → Body-Feld zweck, --betrag → Body-Feld betragCents, --faelligkeit → Body-Feld faelligkeit, --zahlweise → Body-Feld zahlweise, --raten → Body-Feld ratenFaelligkeiten, --zufuehrungsSchluessel → Body-Feld zufuehrungsSchluessel, --entnahmeSchluessel → Body-Feld entnahmeSchluessel, --abweichungsBeschluss → Body-Feld abweichungsBeschlussRef
• Body: Pflicht (--data '<json>')

casa objekt sonderumlage soll

Stellt eine Sonderumlage Soll: Verteilung nach Miteigentumsanteil auf die Einheiten, Teilung in Raten, Schuldner je Rate ist der Eigentümer am Fälligkeitstag. Pflicht: --sonderumlageId <uuid>. Optional --laufTyp sonderzufuehrung (Vorgabe) und --abweichungsBeschluss. Append-only: ein zweiter Aufruf stellt nichts neu und antwortet mit ausgang bereits_ausgefuehrt (Erfolg, Exit 0). Das gestellte Soll zeigt casa objekt sonderumlage show.

casa objekt sonderumlage soll <id> [--sonderumlageId <wert>] [--laufTyp <wert>] [--abweichungsBeschluss <wert>] --data '<json>'

• Endpunkt: POST /api/objekt/{id}/sonderumlage/soll
• Token nötig: ja
• Argumente: <id> (exakte Stelligkeit — zu viele sind ebenfalls ein Bedienfehler)
• Body-Flags: --sonderumlageId → Body-Feld sonderumlageId, --laufTyp → Body-Feld laufTyp, --abweichungsBeschluss → Body-Feld abweichungsBeschlussRef
• Body: Pflicht (--data '<json>')

casa objekt wirtschaftsplan list

Listet die Versionen der Wirtschaftspläne eines Objekts (Jahr und Version aufsteigend, mit Status und Jahres-Soll). --jahr <wirtschaftsjahr> filtert; ein Jahr ohne Plan ergibt eine LEERE Liste, keinen Fehler. Geld ist ein Objekt {cents, currency}.

casa objekt wirtschaftsplan list <id> [--jahr <wert>]

• Endpunkt: GET /api/objekt/{id}/wirtschaftsplan
• Token nötig: ja
• Argumente: <id> (exakte Stelligkeit — zu viele sind ebenfalls ein Bedienfehler)
• Query-Flags: --jahr
• Body: keiner

casa objekt wirtschaftsplan show

Liest EINE Version eines Wirtschaftsplans: --jahr <wirtschaftsjahr> --version <n> (beide Pflicht). --vergleichMit <n> liefert zusätzlich den Diff von --version zur genannten Version; --berechnung true liefert Gesamtplan, Einzelpläne mit Monatsbeträgen und Befunde (serverseitig gerechnet). Geld ist ein Objekt {cents, currency}.

casa objekt wirtschaftsplan show <id> [--jahr <wert>] [--version <wert>] [--vergleichMit <wert>] [--berechnung <wert>]

• Endpunkt: GET /api/objekt/{id}/wirtschaftsplan/stand
• Token nötig: ja
• Argumente: <id> (exakte Stelligkeit — zu viele sind ebenfalls ein Bedienfehler)
• Query-Flags: --jahr, --version, --vergleichMit, --berechnung
• Body: keiner

casa objekt wirtschaftsplan anlegen

Legt den Wirtschaftsplan eines Objekts für ein Wirtschaftsjahr als Version 1 (Status entwurf) an. --data '{"jahr":2027,"positionen":[{"kostenart":"Hausmeister","art":"kosten","betrag":{"cents":"1200000","currency":"EUR"},"verteilerschluessel":"mea"},{"kostenart":"Erhaltung","art":"ruecklagenzufuehrung","betrag":{"cents":"600000","currency":"EUR"},"ruecklageId":"<uuid>"}]}'. Geld ist ein Objekt {cents, currency} (cents als Ziffern-String). art: kosten · einnahme · ruecklagenzufuehrung. Bei einem Objekt mit abweichendem Wirtschaftsjahr zusätzlich "beginn" und "ende" (YYYY-MM-DD).

casa objekt wirtschaftsplan anlegen <id> --data '<json>'

• Endpunkt: POST /api/objekt/{id}/wirtschaftsplan
• Token nötig: ja
• Argumente: <id> (exakte Stelligkeit — zu viele sind ebenfalls ein Bedienfehler)
• Body: Pflicht (--data '<json>')

casa objekt wirtschaftsplan bearbeiten

Bearbeitet den Entwurf: bearbeiten legt eine neue Version an, die alte bleibt. --data '{"jahr":2027,"positionen":[{"kostenart":"Hausmeister","art":"kosten","betrag":{"cents":"1300000","currency":"EUR"},"verteilerschluessel":"mea"}]}' — die VOLLSTÄNDIGE Positionsliste, kein Teil-Patch. Geld ist ein Objekt {cents, currency}. Ohne bestehenden Plan: erst anlegen.

casa objekt wirtschaftsplan bearbeiten <id> --data '<json>'

• Endpunkt: POST /api/objekt/{id}/wirtschaftsplan/entwurf
• Token nötig: ja
• Argumente: <id> (exakte Stelligkeit — zu viele sind ebenfalls ein Bedienfehler)
• Body: Pflicht (--data '<json>')

casa objekt wirtschaftsplan verwerfen

Verwirft eine Version im Status entwurf; ihre Positionen bleiben lesbar. --data '{"jahr":2027,"version":2}'. Ein beschlossener oder bereits verworfener Plan bleibt unverändert (Konflikt).

casa objekt wirtschaftsplan verwerfen <id> --data '<json>'

• Endpunkt: POST /api/objekt/{id}/wirtschaftsplan/verwerfen
• Token nötig: ja
• Argumente: <id> (exakte Stelligkeit — zu viele sind ebenfalls ein Bedienfehler)
• Body: Pflicht (--data '<json>')

casa objekt wirtschaftsplan beschliessen

Beschließt eine Version im Status entwurf: bindet sie an den tragenden Beschluss und setzt sie auf beschlossen (beschliesse_wirtschaftsplan). --data '{"jahr":2025,"version":2}' --beschluss <ref> (landet als beschlussRef). Die Referenz (beschluss-gegenstand:<uuid>) stammt aus casa objekt beschluss list; der Beschluss muss tragend sein, sonst bleibt der Plan Entwurf (Konflikt). Beschlossen wird nur die höchste Version des Jahres; dieselbe Referenz noch einmal ist ein No-op (bereits_beschlossen). Die Bindung ist unveränderlich.

casa objekt wirtschaftsplan beschliessen <id> [--beschluss <wert>] --data '<json>'

• Endpunkt: POST /api/objekt/{id}/wirtschaftsplan/beschluss
• Token nötig: ja
• Argumente: <id> (exakte Stelligkeit — zu viele sind ebenfalls ein Bedienfehler)
• Body-Flags: --beschluss → Body-Feld beschlussRef
• Body: Pflicht (--data '<json>')

casa objekt wirtschaftsplan uebernehmen

Übernimmt den beschlossenen Wirtschaftsplan ins Hausgeld-Soll und stellt es fällig (uebernehme_wirtschaftsplan_ins_hausgeld_soll). --data '{"jahr":2025,"geldkreis":"weg_hausgeld"}' — ohne Zahlen: der Monatsbetrag ist der Jahresanteil je Einheit auf zwölf Monate, die Rücklage wird getrennt geführt. Rückwirkende Differenzen kommen nur als Vorschlag zurück und werden nicht gebucht (Quittierung: casa objekt hausgeld differenz). Ohne eigenen Plan im Jahr gilt der letzte beschlossene Plan weiter — gilt nur, wenn der Beschluss sie trägt; die Antwort nennt quelle (eigener_plan \| fortgeltung) und quelleJahr.

casa objekt wirtschaftsplan uebernehmen <id> --data '<json>'

• Endpunkt: POST /api/objekt/{id}/wirtschaftsplan/hausgeld-soll
• Token nötig: ja
• Argumente: <id> (exakte Stelligkeit — zu viele sind ebenfalls ein Bedienfehler)
• Body: Pflicht (--data '<json>')

kaution

casa kaution liste

Listet die Kautionen: vereinbart, erhalten, offen und die getrennte Anlage (§ 551 BGB). --propertyId <uuid> grenzt auf EIN Objekt ein, --stichtag JJJJ-MM-TT misst die Eingänge auf einen Tag (Default heute, SERVER-Uhr), --archiveScope alle\|aktiv\|archiviert steuert die Archiv-Kette. --abrechnungsstand abgerechnet\|nicht-abgerechnet\|abrechnungsreif filtert auf den Abrechnungsstand (abrechnungsreif = Vertrag beendet und nicht abgerechnet; eine Bürgschaft nie); jede Zeile trägt abrechnung (null = nicht abgerechnet). Alle Cent-Felder sind vorzeichenbehaftete Integer-STRINGS; "offenCents" ist POSITIV bei Rückstand (Win-CASA rechnet in KAUTIONSLIST.OFFEN umgekehrt). Ein dokumentarisch übernommener Bestand steht auf status "eingang-unbekannt" und trägt mahnbarerRestCents "0" — er wird durch die Umstellung NICHT gemahnt. "summen" summiert nur die EUR-Zeilen; Zeilen in anderen Währungen (etwa ein dokumentarischer CHF-Bestand) stehen je Währung getrennt in "summenFremdwaehrung". "anlagenOhneSachkonto" nennt Kautionskonten ohne zugeordnetes Bank-Sachkonto: deren Eingänge konnten nicht mitgezählt werden. ACHTUNG: die Antwort trägt personenbezogene Daten (Mietpartei, IBAN der Anlage).

casa kaution liste [--propertyId <wert>] [--stichtag <wert>] [--archiveScope <wert>] [--abrechnungsstand <wert>]

• Endpunkt: GET /api/kaution
• Token nötig: ja
• Query-Flags: --propertyId, --stichtag, --archiveScope, --abrechnungsstand
• Body: keiner

casa kaution abrechnung-stand

Liest den gespeicherten Abrechnungsstand EINES Vertrags: --contractId <uuid>. Die Antwort trägt die nicht stornierte Kautionsabrechnung mit Auszahlung, Restforderung und Rückbehalt-Status "keiner" \| "gehalten" \| "freigegeben". Fremder oder unbekannter Vertrag ⇒ 404; Vertrag ohne geltende Abrechnung ⇒ 404 mit Code KAUTION_KEINE_ABRECHNUNG. Cent-Felder sind Integer-STRINGS. ACHTUNG: "rueckbehaltBegruendung" ist Freitext (personenbezogen).

casa kaution abrechnung-stand [--contractId <wert>]

• Endpunkt: GET /api/kaution/abrechnung
• Token nötig: ja
• Query-Flags: --contractId
• Body: keiner

casa kaution zinsstand

Zeigt je Kautions-Anlagekonto (Kontoart kautionskonto) den Zinsstand: "von"/"bis" des zuletzt gebuchten Zinszeitraums ("bis": null, wenn noch kein Zinslauf gebucht ist), "anzahlBarkautionen" auf dem Konto und "unverteilteUmsaetze" — Haben-Umsätze, die noch kein Buchungsanspruch (Eingang) belegt, mit Betrag (Integer-STRING in Cent) und Wertstellung. Ob ein Umsatz ein Zins ist, entscheidet der Befehl nicht; "naechstesOffenesJahr" ist die Eingabe --jahr des Zinslauf-Vorschlags (kaution zinsen vorschlag). Nur lesend; zeigt nur Konten der Objekte, für die der Aufrufer zuständig ist.

casa kaution zinsstand

• Endpunkt: GET /api/kaution/zinsen/stand
• Token nötig: ja
• Body: keiner

casa kaution fristen

Zeigt je gehaltenem Rückbehalt (Kautionsabrechnung im Status "gehalten" oder "teilfreigegeben", nicht storniert) das Fristende und die Überfälligkeit: Vertrag, "abrechnungsdatum", "rueckbehaltCents" und "restCents" (Integer-STRINGS in Cent), "fristEnde" (beim Buchen gespeicherter Termin (Wiedervorlage am): Abrechnungsdatum + Frist des Mandanten zum Buchungszeitpunkt, siehe "kaution einstellung"; eine spätere Änderung der Frist wirkt nur auf neue Abrechnungen), "ueberfaellig" und "tageUeberfaellig". Optional --stichtag <JJJJ-MM-TT> (Vorgabe: heute, Server-Uhr) und --nurUeberfaellig <true\|false>. Nur lesend — keine automatische Aktion, keine Mail; zeigt nur Rückbehalte der Objekte, für die der Aufrufer zuständig ist.

casa kaution fristen [--stichtag <wert>] [--nurUeberfaellig <wert>]

• Endpunkt: GET /api/kaution/rueckbehalt-fristen
• Token nötig: ja
• Query-Flags: --stichtag, --nurUeberfaellig
• Body: keiner

casa kaution abrede

Hält die Kautionsabrede eines Vertrags fest: Betrag + Währung, Anlageform ("barkaution" \| "buergschaft" \| "verpfaendung"), Raten nach § 551 Abs. 2 BGB (1…3, nur und Pflicht bei Barkaution) und die getrennte Anlage. Braucht --data '{"depositCents":"240000","depositCurrency":"EUR","kautionAnlageform":"barkaution","kautionRaten":3,"kautionAnlagekontoId":"<uuid>"}' — depositCents/depositCurrency nur gemeinsam und Pflicht, wenn der Vertrag noch keine Kaution dokumentiert (sonst gilt der dokumentierte Betrag); kautionAnlagekontoId ist eine Bankverbindung der Kontoart kautionskonto am Objekt und Voraussetzung für "kaution eingang". Erst danach stellt "kaution sollstellen" Raten; ohne Abrede bleibt eine übernommene Kaution dokumentarisch ("vereinbart, Eingang unbekannt") und wird nie gemahnt. Mehr als 3 Raten ⇒ 400; sind schon Raten oder Eingänge gebucht ⇒ 409.

casa kaution abrede <id> --data '<json>'

• Endpunkt: POST /api/vertrag/{id}/kaution
• Token nötig: ja
• Argumente: <id> (exakte Stelligkeit — zu viele sind ebenfalls ein Bedienfehler)
• Body: Pflicht (--data '<json>')

casa kaution einstellung

Zeigt die Kaution-Einstellung des Mandanten: "rueckbehaltFristMonate" (Frist des Rückbehalts bei unklaren Forderungen, beginnt mit dem Abrechnungsdatum der Kautionsabrechnung; Vorgabe 6 Monate) und "istVorgabe" (true, solange der Mandant nichts eingestellt hat). Ändern: "kaution einstellung --monate <1…36>" (PUT, ganze Zahl; Admin-Recht nötig; wiederholungssicher mit --idempotency-key) oder "kaution einstellung setzen".

casa kaution einstellung [--monate <ganze Zahl>]

• Endpunkt: GET /api/kaution/einstellung
• Token nötig: ja
• Schreib-Flag: --monate <ganze Zahl> → PUT mit Body-Feld monate (ohne das Flag: GET)
• Body: keiner

casa kaution einstellung setzen

Setzt die Frist des Rückbehalts des Mandanten. Braucht --data '{"monate":9}' — eine ganze Zahl 1…36 (sonst 400, nichts geschrieben). Nur ein Mensch mit Admin-Recht (sonst 403). Gilt nur für neue Abrechnungen: Bestehende behalten das beim Buchen festgeschriebene Wiedervorlage-Datum. Antwort: "rueckbehaltFristMonate" (der gesetzte Wert) und "istVorgabe" (false). Wiederholungssicher mit --idempotency-key.

casa kaution einstellung setzen --data '<json>'

• Endpunkt: PUT /api/kaution/einstellung
• Token nötig: ja
• Body: Pflicht (--data '<json>')

casa kaution vorschlag

Berechnet den VORSCHLAG einer Kautionsbuchung, ohne zu schreiben: --art sollstellung --contractId <uuid> [--stichtag JJJJ-MM-TT] (die bis zum Stichtag fälligen Raten) oder --art eingang --bankTransactionId <uuid> --contractId <uuid> (ein Umsatz des hinterlegten Kautionskontos). Braucht --data '{}'. Die Antwort trägt den ganzen Inhalt und "vorschlagHash" — mit genau diesem Hash wird freigegeben ("kaution freigeben") und gebucht ("kaution sollstellen" / "kaution eingang"). "status" sagt, ob dieser Inhalt schon freigegeben ist.

casa kaution vorschlag [--art <wert>] [--contractId <wert>] [--stichtag <wert>] [--bankTransactionId <wert>] --data '<json>'

• Endpunkt: POST /api/kaution/vorschlag
• Token nötig: ja
• Body-Flags: --art → Body-Feld art, --contractId → Body-Feld contractId, --stichtag → Body-Feld stichtag, --bankTransactionId → Body-Feld bankTransactionId
• Body: Pflicht (--data '<json>')

casa kaution freigeben

Gibt einen Kautions-Vorschlag frei — gebunden an GENAU den Inhalt mit diesem Hash. Braucht --data '{}' plus dieselben Angaben wie "kaution vorschlag" (--art, --contractId, ggf. --stichtag bzw. --bankTransactionId) und --vorschlagHash <hash>. Hat sich der Inhalt seit dem Vorschlag geändert ⇒ 409 (neu vorschlagen); ohne Schreibrecht ⇒ 403; eine zweite Freigabe desselben Inhalts ⇒ 409. Ohne Freigabe buchen "kaution sollstellen" und "kaution eingang" nichts.

casa kaution freigeben [--art <wert>] [--contractId <wert>] [--stichtag <wert>] [--bankTransactionId <wert>] [--vorschlagHash <wert>] --data '<json>'

• Endpunkt: POST /api/kaution/freigabe
• Token nötig: ja
• Body-Flags: --art → Body-Feld art, --contractId → Body-Feld contractId, --stichtag → Body-Feld stichtag, --bankTransactionId → Body-Feld bankTransactionId, --vorschlagHash → Body-Feld vorschlagHash
• Body: Pflicht (--data '<json>')

casa kaution sollstellen

Stellt die bis zum Stichtag fälligen Kautionsraten eines Vertrags soll — SOLL Kautions-Personenkonto des Mieters (eigenes Debitorkonto, getrennt vom Mietkonto) / HABEN Kaution, je Rate ein Satz. Braucht --data '{}' plus --contractId <uuid> und --vorschlagHash <hash> eines FREIGEGEBENEN Vorschlags ("kaution vorschlag" → "kaution freigeben"); --stichtag JJJJ-MM-TT wie im Vorschlag (Default heute, nie in der Zukunft). Ohne gültige Freigabe (fehlt, abgelehnt, Inhalt seither geändert) ⇒ 409, nichts gebucht. Die Antwort zeigt den ganzen Ratenplan mit "status" je Rate (sollgestellt · bereits-sollgestellt · nicht-faellig); ein zweiter Aufruf bucht nichts doppelt ("neuSollgestellt": 0). Ein Vertrag ohne Kautionsabrede (übernommener Bestand) und eine Bürgschaft/Verpfändung (kein Zahlungsstrom) enden mit 409 statt einer Forderung. Cent-Felder sind Integer-STRINGS.

casa kaution sollstellen [--contractId <wert>] [--stichtag <wert>] [--vorschlagHash <wert>] --data '<json>'

• Endpunkt: POST /api/kaution/sollstellung
• Token nötig: ja
• Body-Flags: --contractId → Body-Feld contractId, --stichtag → Body-Feld stichtag, --vorschlagHash → Body-Feld vorschlagHash
• Body: Pflicht (--data '<json>')

casa kaution eingang

Verbucht einen Bankumsatz des am Vertrag hinterlegten Kautionskontos als Eingang der Kaution — Bank an Kautions-Personenkonto des Mieters, mit Buchungsanspruch und Tilgung der offenen Raten (älteste zuerst), OHNE Zuordnung zum Mietkonto. Braucht --data '{}' plus --bankTransactionId <uuid> --contractId <uuid> --vorschlagHash <hash> eines FREIGEGEBENEN Vorschlags ("kaution vorschlag --art eingang" → "kaution freigeben"); ohne gültige Freigabe ⇒ 409, nichts gebucht. Danach zeigt "kaution liste" den Betrag unter "erhaltenCents". Wiederholen bucht nichts doppelt ("replay": true). 409, wenn der Umsatz nicht auf dem hinterlegten Kautionskonto liegt, keine Abrede besteht oder die Kaution eine Bürgschaft/Verpfändung ist (kein Zahlungsstrom).

casa kaution eingang [--bankTransactionId <wert>] [--contractId <wert>] [--vorschlagHash <wert>] --data '<json>'

• Endpunkt: POST /api/kaution/eingang
• Token nötig: ja
• Body-Flags: --bankTransactionId → Body-Feld bankTransactionId, --contractId → Body-Feld contractId, --vorschlagHash → Body-Feld vorschlagHash
• Body: Pflicht (--data '<json>')

casa kaution festzins

Pflegt den Zinssatz EINES Kautionskontos „gültig ab heute" (Eintrag der Satzhistorie mit dem heutigen Verwaltungstag). Braucht --data '{"bankAccountId":"<uuid>","basispunkte":150}' — basispunkte ist eine Zahl 0…2000 (150 = 1,50 %) oder null, um den Eintrag von heute zu löschen. Für ein anderes Datum: "kaution zinssatz setzen". Reine Stammdatenänderung ohne Buchung und ohne Freigabe. Der am Stichtag gültige Satz erscheint als "festzinsBasispunkte" in "kaution zinsstand". Nur ein Mensch; ein Konto einer anderen Art oder ein heute in einem gebuchten Zinszeitraum ⇒ 409, ein unbekanntes, fremdes oder nicht zuständiges Konto ⇒ 404, Satz außerhalb 0…2000 ⇒ 400.

casa kaution festzins --data '<json>'

• Endpunkt: PUT /api/kaution/zinsen/festzins
• Token nötig: ja
• Body: Pflicht (--data '<json>')

casa kaution zinssatz liste

Zeigt die Satzhistorie „gültig ab" EINES Kautionskontos, aufsteigend nach "gueltigAb": je Eintrag "basispunkte" (150 = 1,50 %), "erfasstVon" ("migration" für den übernommenen Altbestand, gültig ab 1900-01-01) und "erfasstAm". Braucht --bankAccountId <uuid>. Der Satz an einem Tag ist der Eintrag mit dem größten "gueltigAb" bis zu diesem Tag; vor dem ersten Eintrag gilt kein Satz. Ein fremdes, unbekanntes oder nicht zuständiges Konto ⇒ 404 (Fehler, keine leere Liste). Nur lesend.

casa kaution zinssatz liste [--bankAccountId <wert>]

• Endpunkt: GET /api/kaution/zinsen/saetze
• Token nötig: ja
• Query-Flags: --bankAccountId
• Body: keiner

casa kaution zinssatz setzen

Schreibt EINEN Eintrag der Satzhistorie eines Kautionskontos. Braucht --data '{"bankAccountId":"<uuid>","gueltigAb":"2025-07-01","basispunkte":75}' — gueltigAb (JJJJ-MM-TT) ist Pflicht; ein vorhandener Eintrag desselben Tages wird überschrieben (ein wiederholter gleicher Aufruf ändert nichts), basispunkte null löscht den Eintrag dieses Tages (ohne Eintrag ⇒ 404). Ein gueltigAb in einem gebuchten Zinszeitraum des Kontos ⇒ 409, nichts geschrieben; ebenso ein Konto anderer Art ⇒ 409. Reine Stammdatenänderung ohne Buchung und ohne Freigabe. Nur ein Mensch; ein unbekanntes, fremdes oder nicht zuständiges Konto ⇒ 404, Satz außerhalb 0…2000 oder ungültiges Datum ⇒ 400.

casa kaution zinssatz setzen --data '<json>'

• Endpunkt: POST /api/kaution/zinsen/saetze
• Token nötig: ja
• Body: Pflicht (--data '<json>')

casa kaution zinsen vorschlag

Berechnet den VORSCHLAG des Jahreszinslaufs eines Kautionskontos, ohne zu schreiben: der Zins je Kaution für das nächste offene Kalenderjahr (Stand zum 01.01., Zinstage, Satz bzw. Sätze, Zins), dazu die Summe. Braucht --data '{}' plus --bankAccountId <uuid> --jahr JJJJ; erlaubt ist nur "naechstesOffenesJahr" aus "kaution zinsstand" (sonst 409), ein Jahr, dessen 31.12. in der Zukunft liegt, ⇒ 400, ein Tag mit Kapital ohne Zinssatz ⇒ 409 (erst "kaution zinssatz setzen"). Die Antwort trägt "vorschlagHash" und "status". Hash-Ablauf: der Vorschlag selbst verlangt keinen Hash, er liefert ihn. Erst die Folgebefehle (kaution zinsen freigeben, ein Mensch mit Schreibrecht, kein Vier-Augen-Prinzip, dann kaution zinsen buchen) verlangen --vorschlagHash und brechen ohne ihn ab, nichts wird gesendet; ein falscher oder nicht freigegebener Hash ⇒ 409 (Code conflict), nichts gebucht.

casa kaution zinsen vorschlag [--bankAccountId <wert>] [--jahr <wert>] --data '<json>'

• Endpunkt: POST /api/kaution/zinsen/vorschlag
• Token nötig: ja
• Body-Flags: --bankAccountId → Body-Feld bankAccountId, --jahr → Body-Feld jahr
• Body: Pflicht (--data '<json>')

casa kaution zinsen freigeben

Gibt den Zinsjahr-Vorschlag frei — gebunden an GENAU den Inhalt mit diesem Hash. Braucht --data '{}' plus --bankAccountId --jahr wie im Vorschlag und --vorschlagHash <hash>. Hash-Ablauf: erst den Vorschlag holen (kaution zinsen vorschlag), dann freigeben (kaution zinsen freigeben, ein Mensch mit Schreibrecht, kein Vier-Augen-Prinzip), dann mit genau diesem --vorschlagHash ausführen. Ohne --vorschlagHash bricht die CLI ab, nichts wird gesendet; ein falscher oder nicht freigegebener Hash ⇒ 409 (Code conflict), nichts gebucht.

casa kaution zinsen freigeben [--bankAccountId <wert>] [--jahr <wert>] [--vorschlagHash <wert>] --data '<json>'

• Endpunkt: POST /api/kaution/zinsen/freigabe
• Token nötig: ja
• Body-Flags: --bankAccountId → Body-Feld bankAccountId, --jahr → Body-Feld jahr, --vorschlagHash → Body-Feld vorschlagHash
• Body: Pflicht (--data '<json>')

casa kaution zinsen buchen

Bucht das FREIGEGEBENE Zinsjahr: je Kaution ein Satz zum 31.12. SOLL 1481 Zinsforderung Kautionskonto an HABEN Kautions-Personenkonto (kein Bankumsatz-Anspruch). Braucht --data '{}' plus --bankAccountId --jahr und --vorschlagHash. Wiederholen bucht nichts doppelt ("neuGebucht"). Hash-Ablauf: erst den Vorschlag holen (kaution zinsen vorschlag), dann freigeben (kaution zinsen freigeben, ein Mensch mit Schreibrecht, kein Vier-Augen-Prinzip), dann mit genau diesem --vorschlagHash ausführen. Ohne --vorschlagHash bricht die CLI ab, nichts wird gesendet; ein falscher oder nicht freigegebener Hash ⇒ 409 (Code conflict), nichts gebucht.

casa kaution zinsen buchen [--bankAccountId <wert>] [--jahr <wert>] [--vorschlagHash <wert>] --data '<json>'

• Endpunkt: POST /api/kaution/zinsen/buchung
• Token nötig: ja
• Body-Flags: --bankAccountId → Body-Feld bankAccountId, --jahr → Body-Feld jahr, --vorschlagHash → Body-Feld vorschlagHash
• Body: Pflicht (--data '<json>')

casa kaution zinsen gutschrift vorschlag

Berechnet den VORSCHLAG der Zuordnung einer Bankgutschrift zu einem Zinsjahr (Art gutschrift), ohne zu schreiben. Braucht --data '{}' plus --bankTransactionId <uuid> (Haben-Umsatz auf einem Kautionskonto, Zinsgutschrift der Bank; kein Haben-Umsatz oder falsche Kontoart ⇒ 409, fremder oder unbekannter Umsatz ⇒ 404). OHNE --jahr JJJJ listet die Antwort die Jahre mit offenem Saldo auf dem Konto 1481 Zinsforderung ("offeneJahre", mit "saldoCents"); mit --jahr (eines der offenen Jahre, sonst 409) liefert sie Differenz und Anteile: Mehrbetrag der Bank über dem Saldo geht an die Mieter nach Guthaben × Tagen ("mehrbetragCents" je Kaution; bei einer schon ausgezahlten Kaution ab 1,00 € zusätzlich als Zahlungsauftrag zur Freigabe an den gespeicherten Empfänger der Kautionsauszahlung, darunter trägt der Vermieter den Anteil auf 58600), Minderbetrag trägt der Vermieter auf 58600, bei gleichem Betrag wird nur Bank an 1481 gebucht. Die Antwort trägt "vorschlagHash" und "status". Hash-Ablauf: der Vorschlag selbst verlangt keinen Hash, er liefert ihn. Erst die Folgebefehle (kaution zinsen gutschrift freigeben, ein Mensch mit Schreibrecht, kein Vier-Augen-Prinzip, dann kaution zinsen gutschrift buchen) verlangen --vorschlagHash und brechen ohne ihn ab, nichts wird gesendet; ein falscher oder nicht freigegebener Hash ⇒ 409 (Code conflict), nichts gebucht.

casa kaution zinsen gutschrift vorschlag [--bankTransactionId <wert>] [--jahr <wert>] --data '<json>'

• Endpunkt: POST /api/kaution/zinsen/vorschlag
• Token nötig: ja
• Body-Flags: --bankTransactionId → Body-Feld bankTransactionId, --jahr → Body-Feld jahr
• Feste Body-Felder: art = gutschrift
• Body: Pflicht (--data '<json>')

casa kaution zinsen gutschrift freigeben

Gibt die Zuordnung der Bankgutschrift zu einem Zinsjahr frei — gebunden an GENAU den Inhalt mit diesem Hash. Braucht --data '{}' plus --bankTransactionId --jahr wie im Vorschlag und --vorschlagHash <hash>. Hash-Ablauf: erst den Vorschlag holen (kaution zinsen gutschrift vorschlag --jahr JJJJ), dann freigeben (kaution zinsen gutschrift freigeben, ein Mensch mit Schreibrecht, kein Vier-Augen-Prinzip), dann mit genau diesem --vorschlagHash ausführen. Ohne --vorschlagHash bricht die CLI ab, nichts wird gesendet; ein falscher oder nicht freigegebener Hash ⇒ 409 (Code conflict), nichts gebucht.

casa kaution zinsen gutschrift freigeben [--bankTransactionId <wert>] [--jahr <wert>] [--vorschlagHash <wert>] --data '<json>'

• Endpunkt: POST /api/kaution/zinsen/freigabe
• Token nötig: ja
• Body-Flags: --bankTransactionId → Body-Feld bankTransactionId, --jahr → Body-Feld jahr, --vorschlagHash → Body-Feld vorschlagHash
• Feste Body-Felder: art = gutschrift
• Body: Pflicht (--data '<json>')

casa kaution zinsen gutschrift buchen

Bucht die FREIGEGEBENE Zuordnung der Bankgutschrift zu einem Zinsjahr: EIN Satz Bank an 1481 in Höhe des offenen Saldos, der Mehrbetrag an die Kautions-Personenkonten (Guthaben × Tage; schon ausgezahlte Kaution ab 1,00 € zusätzlich als Zahlungsauftrag zur Freigabe, darunter 58600), ein Minderbetrag 58600 an 1481. Der Bankumsatz wird beansprucht: derselbe Umsatz ein zweites Mal ⇒ 409, nichts gebucht. Braucht --data '{}' plus --bankTransactionId --jahr und --vorschlagHash. Hash-Ablauf: erst den Vorschlag holen (kaution zinsen gutschrift vorschlag --jahr JJJJ), dann freigeben (kaution zinsen gutschrift freigeben, ein Mensch mit Schreibrecht, kein Vier-Augen-Prinzip), dann mit genau diesem --vorschlagHash ausführen. Ohne --vorschlagHash bricht die CLI ab, nichts wird gesendet; ein falscher oder nicht freigegebener Hash ⇒ 409 (Code conflict), nichts gebucht.

casa kaution zinsen gutschrift buchen [--bankTransactionId <wert>] [--jahr <wert>] [--vorschlagHash <wert>] --data '<json>'

• Endpunkt: POST /api/kaution/zinsen/buchung
• Token nötig: ja
• Body-Flags: --bankTransactionId → Body-Feld bankTransactionId, --jahr → Body-Feld jahr, --vorschlagHash → Body-Feld vorschlagHash
• Feste Body-Felder: art = gutschrift
• Body: Pflicht (--data '<json>')

casa kaution zinsen storno vorschlag

Berechnet den VORSCHLAG des Stornos des ZULETZT gebuchten Zinsjahres eines Kautionskontos, ohne zu schreiben: je Kaution der Jahreszinssatz, der gegengebucht würde, die Summe und die Generation. Braucht --data '{}' plus --bankAccountId <uuid> --jahr JJJJ --grund <Text, 1 bis 500 Zeichen, Pflicht>. Nur das zuletzt gebuchte Jahr (sonst 409), nur ohne zugeordnete Bankgutschrift (sonst 409) und ohne abgerechnete Kaution (sonst 409); ein fremdes oder unbekanntes Konto => 404. Die Antwort trägt "vorschlagHash" und "status". Hash-Ablauf: der Vorschlag selbst verlangt keinen Hash, er liefert ihn. Erst die Folgebefehle (kaution zinsen storno freigeben, ein Mensch mit Schreibrecht, kein Vier-Augen-Prinzip, dann kaution zinsen storno ausfuehren) verlangen --vorschlagHash und brechen ohne ihn ab, nichts wird gesendet; ein falscher oder nicht freigegebener Hash => 409 (Code conflict), nichts storniert.

casa kaution zinsen storno vorschlag [--bankAccountId <wert>] [--jahr <wert>] [--grund <wert>] --data '<json>'

• Endpunkt: POST /api/kaution/zinsen/storno
• Token nötig: ja
• Body-Flags: --bankAccountId → Body-Feld bankAccountId, --jahr → Body-Feld jahr, --grund → Body-Feld grund
• Feste Body-Felder: stufe = vorschlag
• Body: Pflicht (--data '<json>')

casa kaution zinsen storno freigeben

Gibt den Storno-Vorschlag des Zinsjahres frei — gebunden an GENAU den Inhalt mit diesem Hash (Artefakt-Art kautionszinsjahr-storno). Braucht --data '{}' plus --bankAccountId --jahr --grund wie im Vorschlag und --vorschlagHash <hash>. Hash-Ablauf: erst den Vorschlag holen (kaution zinsen storno vorschlag), dann freigeben (kaution zinsen storno freigeben, ein Mensch mit Schreibrecht, kein Vier-Augen-Prinzip), dann mit genau diesem --vorschlagHash ausführen (kaution zinsen storno ausfuehren). Ohne --vorschlagHash bricht die CLI ab, nichts wird gesendet; ein falscher oder nicht freigegebener Hash => 409 (Code conflict), nichts gebucht.

casa kaution zinsen storno freigeben [--bankAccountId <wert>] [--jahr <wert>] [--grund <wert>] [--vorschlagHash <wert>] --data '<json>'

• Endpunkt: POST /api/kaution/zinsen/storno
• Token nötig: ja
• Body-Flags: --bankAccountId → Body-Feld bankAccountId, --jahr → Body-Feld jahr, --grund → Body-Feld grund, --vorschlagHash → Body-Feld vorschlagHash
• Feste Body-Felder: stufe = freigabe
• Body: Pflicht (--data '<json>')

casa kaution zinsen storno ausfuehren

Storniert das FREIGEGEBENE Zinsjahr: je Kaution die Gegenbuchung des Jahreszinssatzes; danach ist das Jahr wieder das nächste offene Zinsjahr und bucht unter der nächsten Generation neu. Ein zweiter Aufruf bucht nichts ("neuStorniert": 0). Ein Jahr, das ohne Zins gebucht war (Nullzins-Marke), hat nichts zum Gegenbuchen: der Storno öffnet es trotzdem wieder ("neuStorniert": 0, "nullzinsjahr": true). Braucht --data '{}' plus --bankAccountId --jahr --grund und --vorschlagHash. Hash-Ablauf: erst den Vorschlag holen (kaution zinsen storno vorschlag), dann freigeben (kaution zinsen storno freigeben, ein Mensch mit Schreibrecht, kein Vier-Augen-Prinzip), dann mit genau diesem --vorschlagHash ausführen (kaution zinsen storno ausfuehren). Ohne --vorschlagHash bricht die CLI ab, nichts wird gesendet; ein falscher oder nicht freigegebener Hash => 409 (Code conflict), nichts gebucht.

casa kaution zinsen storno ausfuehren [--bankAccountId <wert>] [--jahr <wert>] [--grund <wert>] [--vorschlagHash <wert>] --data '<json>'

• Endpunkt: POST /api/kaution/zinsen/storno
• Token nötig: ja
• Body-Flags: --bankAccountId → Body-Feld bankAccountId, --jahr → Body-Feld jahr, --grund → Body-Feld grund, --vorschlagHash → Body-Feld vorschlagHash
• Feste Body-Felder: stufe = ausfuehren
• Body: Pflicht (--data '<json>')

casa kaution zinsen liste

Listet die gebuchten Zinsgutschriften eines Vertrags. Braucht --contractId <uuid>.

casa kaution zinsen liste [--contractId <wert>]

• Endpunkt: GET /api/kaution/zinsen
• Token nötig: ja
• Query-Flags: --contractId
• Body: keiner

casa kaution abrechnung vorschlag

Berechnet den VORSCHLAG einer Kautionsabrechnung (--art abrechnung), einer Rückbehalt-Freigabe (--art rueckbehalt) oder eines Stornos (--art storno), ohne zu schreiben. Der Body hängt von --art ab: abrechnung = --contractId --stichtag --requestedExecutionDate JJJJ-MM-TT (die anteiligen Zinsen vom 01.01. bis zum Abrechnungstag rechnet die Abrechnung selbst und bucht sie mit der Abrechnung auf 1481; fehlt das Zinsjahr des Vorjahres ⇒ 409, erst den Zinslauf ausführen; liegt der Abrechnungstag in einem gebuchten Zinsjahr ⇒ 409, erst das Zinsjahr stornieren) und --data '{"offenePostenIds":[…],"rueckbehalte":[{"grundart":"bk-nachzahlung","betragCents":"…"},{"grundart":"sonstiges","betragCents":"…","begruendung":"…"}]}' (rueckbehalte optional: bk-nachzahlung höchstens einmal, gedeckelt auf die letzte BK-Nachzahlung ohne Aufschlag, bei letztem Guthaben nicht wählbar; sonstiges beliebig oft, frei bis zum Guthaben, Begründung Pflicht); rueckbehalt = --contractId --stichtag --requestedExecutionDate, offenePostenIds in --data, optional --betragCents <Ziffern> für einen Teilbetrag; storno = --kautionsabrechnungId --grund. Die Antwort trägt "vorschlagHash", "status" und den ganzen Inhalt. Hash-Ablauf: der Vorschlag selbst verlangt keinen Hash, er liefert ihn. Erst die Folgebefehle (kaution abrechnung freigeben, ein Mensch mit Schreibrecht, kein Vier-Augen-Prinzip, dann kaution abrechnung ausfuehren bzw. storno bzw. kaution rueckbehalt-freigeben) verlangen --vorschlagHash und brechen ohne ihn ab, nichts wird gesendet; ein falscher oder nicht freigegebener Hash ⇒ 409 (Code conflict), nichts gebucht. Optional --empfaengerBankverbindungId <uuid> wählt den Empfänger der Auszahlung aus den bestätigten Bankverbindungen der Mieter des Vertrags (nur bei art abrechnung; genau eine wählbare Verbindung wird vorbelegt, bei mehreren ohne Wahl steht der Vorschlag auf Zustand empfaenger-offen und Freigabe bzw. Ausführung brechen mit 409 ab; eine nicht bestätigte oder fremde Verbindung ⇒ 409). Der Vorschlag nennt alle waehlbareEmpfaenger; die Wahl ist Teil des Hashs und gilt auch für spätere Rückbehalt-Freigaben.

casa kaution abrechnung vorschlag [--art <wert>] [--contractId <wert>] [--stichtag <wert>] [--requestedExecutionDate <wert>] [--empfaengerBankverbindungId <wert>] [--kautionsabrechnungId <wert>] [--grund <wert>] [--betragCents <wert>] --data '<json>'

• Endpunkt: POST /api/kaution/abrechnung/vorschlag
• Token nötig: ja
• Body-Flags: --art → Body-Feld art, --contractId → Body-Feld contractId, --stichtag → Body-Feld stichtag, --requestedExecutionDate → Body-Feld requestedExecutionDate, --empfaengerBankverbindungId → Body-Feld empfaengerBankverbindungId, --kautionsabrechnungId → Body-Feld kautionsabrechnungId, --grund → Body-Feld grund, --betragCents → Body-Feld betragCents
• Body: Pflicht (--data '<json>')

casa kaution abrechnung freigeben

Gibt den Abrechnungs-, Rückbehalt- oder Storno-Vorschlag frei — gebunden an GENAU den Inhalt mit diesem Hash. Braucht --data und dieselben Angaben wie "kaution abrechnung vorschlag" (--art …) plus --vorschlagHash. Der Body hängt von --art ab: abrechnung = --contractId --stichtag --requestedExecutionDate (die Zinsen rechnet die Abrechnung selbst, keine Eingabe) und --data '{"offenePostenIds":[…],"rueckbehalte":[{"grundart":"bk-nachzahlung","betragCents":"…"},{"grundart":"sonstiges","betragCents":"…","begruendung":"…"}]}' (rueckbehalte optional: bk-nachzahlung höchstens einmal, gedeckelt auf die letzte BK-Nachzahlung ohne Aufschlag, bei letztem Guthaben nicht wählbar; sonstiges beliebig oft, frei bis zum Guthaben, Begründung Pflicht); rueckbehalt = --contractId --stichtag, offenePostenIds in --data, ggf. derselbe --betragCents wie im Vorschlag; storno = --kautionsabrechnungId --grund. Hash-Ablauf: erst den Vorschlag holen (kaution abrechnung vorschlag), dann freigeben (kaution abrechnung freigeben, ein Mensch mit Schreibrecht, kein Vier-Augen-Prinzip), dann mit genau diesem --vorschlagHash ausführen. Ohne --vorschlagHash bricht die CLI ab, nichts wird gesendet; ein falscher oder nicht freigegebener Hash ⇒ 409 (Code conflict), nichts gebucht. Optional --empfaengerBankverbindungId <uuid> wählt den Empfänger der Auszahlung aus den bestätigten Bankverbindungen der Mieter des Vertrags (nur bei art abrechnung; genau eine wählbare Verbindung wird vorbelegt, bei mehreren ohne Wahl steht der Vorschlag auf Zustand empfaenger-offen und Freigabe bzw. Ausführung brechen mit 409 ab; eine nicht bestätigte oder fremde Verbindung ⇒ 409). Der Vorschlag nennt alle waehlbareEmpfaenger; die Wahl ist Teil des Hashs und gilt auch für spätere Rückbehalt-Freigaben.

casa kaution abrechnung freigeben [--art <wert>] [--contractId <wert>] [--stichtag <wert>] [--requestedExecutionDate <wert>] [--empfaengerBankverbindungId <wert>] [--kautionsabrechnungId <wert>] [--grund <wert>] [--betragCents <wert>] [--vorschlagHash <wert>] --data '<json>'

• Endpunkt: POST /api/kaution/abrechnung/freigabe
• Token nötig: ja
• Body-Flags: --art → Body-Feld art, --contractId → Body-Feld contractId, --stichtag → Body-Feld stichtag, --requestedExecutionDate → Body-Feld requestedExecutionDate, --empfaengerBankverbindungId → Body-Feld empfaengerBankverbindungId, --kautionsabrechnungId → Body-Feld kautionsabrechnungId, --grund → Body-Feld grund, --betragCents → Body-Feld betragCents, --vorschlagHash → Body-Feld vorschlagHash
• Body: Pflicht (--data '<json>')

casa kaution abrechnung ausfuehren

Führt die FREIGEGEBENE Kautionsabrechnung aus: verrechnet offene Posten, behält ggf. zurück und legt die Auszahlung als Zahlungsauftrag zur Freigabe an (die CLI zahlt nichts selbst aus). Braucht --contractId --stichtag --requestedExecutionDate (die Zinsen bis zum Abrechnungstag rechnet die Abrechnung selbst), --data '{"offenePostenIds":[…]}' (ggf. mit rueckbehalte) und --vorschlagHash des Vorschlags mit --art abrechnung. Hash-Ablauf: erst den Vorschlag holen (kaution abrechnung vorschlag --art abrechnung), dann freigeben (kaution abrechnung freigeben --art abrechnung, ein Mensch mit Schreibrecht, kein Vier-Augen-Prinzip), dann mit genau diesem --vorschlagHash ausführen. Ohne --vorschlagHash bricht die CLI ab, nichts wird gesendet; ein falscher oder nicht freigegebener Hash ⇒ 409 (Code conflict), nichts gebucht. Optional --empfaengerBankverbindungId <uuid> wählt den Empfänger der Auszahlung aus den bestätigten Bankverbindungen der Mieter des Vertrags (nur bei art abrechnung; genau eine wählbare Verbindung wird vorbelegt, bei mehreren ohne Wahl steht der Vorschlag auf Zustand empfaenger-offen und Freigabe bzw. Ausführung brechen mit 409 ab; eine nicht bestätigte oder fremde Verbindung ⇒ 409). Der Vorschlag nennt alle waehlbareEmpfaenger; die Wahl ist Teil des Hashs und gilt auch für spätere Rückbehalt-Freigaben.

casa kaution abrechnung ausfuehren [--contractId <wert>] [--stichtag <wert>] [--requestedExecutionDate <wert>] [--empfaengerBankverbindungId <wert>] [--vorschlagHash <wert>] --data '<json>'

• Endpunkt: POST /api/kaution/abrechnung
• Token nötig: ja
• Body-Flags: --contractId → Body-Feld contractId, --stichtag → Body-Feld stichtag, --requestedExecutionDate → Body-Feld requestedExecutionDate, --empfaengerBankverbindungId → Body-Feld empfaengerBankverbindungId, --vorschlagHash → Body-Feld vorschlagHash
• Body: Pflicht (--data '<json>')

casa kaution abrechnung storno

Storniert eine ausgeführte Kautionsabrechnung (Verrechnungen werden gegengebucht, offene Zahlungsaufträge storniert). Braucht --data '{}' plus --kautionsabrechnungId <uuid> --grund <text> (Pflicht, ≤ 500 Zeichen) und --vorschlagHash des Vorschlags mit --art storno. Hash-Ablauf: erst den Vorschlag holen (kaution abrechnung vorschlag --art storno), dann freigeben (kaution abrechnung freigeben --art storno; kein Vier-Augen-Prinzip: dieselbe Person darf abrechnen, freigeben und ausführen, die Freigabe selbst muss ein Mensch mit Schreibrecht erteilen), dann mit genau diesem --vorschlagHash ausführen. Ohne --vorschlagHash bricht die CLI ab, nichts wird gesendet; ein falscher oder nicht freigegebener Hash ⇒ 409 (Code conflict), nichts gebucht.

casa kaution abrechnung storno [--kautionsabrechnungId <wert>] [--grund <wert>] [--vorschlagHash <wert>] --data '<json>'

• Endpunkt: POST /api/kaution/abrechnung/storno
• Token nötig: ja
• Body-Flags: --kautionsabrechnungId → Body-Feld kautionsabrechnungId, --grund → Body-Feld grund, --vorschlagHash → Body-Feld vorschlagHash
• Body: Pflicht (--data '<json>')

casa kaution rueckbehalt-freigeben

Gibt den bei der Abrechnung einbehaltenen Rückbehalt frei: verrechnet jetzt fällige Posten (z. B. die BK-Nachzahlung) und legt die Auszahlung als Zahlungsauftrag zur Freigabe an. Braucht --contractId --stichtag --requestedExecutionDate JJJJ-MM-TT, --data '{"offenePostenIds":[…]}' und --vorschlagHash des Vorschlags mit --art rueckbehalt. Optional --betragCents <Ziffern> gibt nur einen TEILBETRAG in Cent frei (Ziffern-String, 0 < Teilbetrag ≤ Rest, sonst 409): der Rückbehalt ist danach teilfreigegeben mit Rest, der letzte Schritt (Rest 0) gibt ihn ganz frei; ohne --betragCents wird der ganze Rest freigegeben. Jeder Teilschritt braucht seinen eigenen Vorschlag und seine eigene Freigabe mit demselben --betragCents. Hash-Ablauf: erst den Vorschlag holen (kaution abrechnung vorschlag --art rueckbehalt), dann freigeben (kaution abrechnung freigeben --art rueckbehalt, ein Mensch mit Schreibrecht, kein Vier-Augen-Prinzip), dann mit genau diesem --vorschlagHash ausführen. Ohne --vorschlagHash bricht die CLI ab, nichts wird gesendet; ein falscher oder nicht freigegebener Hash ⇒ 409 (Code conflict), nichts gebucht.

casa kaution rueckbehalt-freigeben [--contractId <wert>] [--stichtag <wert>] [--requestedExecutionDate <wert>] [--betragCents <wert>] [--vorschlagHash <wert>] --data '<json>'

• Endpunkt: POST /api/kaution/rueckbehalt-freigabe
• Token nötig: ja
• Body-Flags: --contractId → Body-Feld contractId, --stichtag → Body-Feld stichtag, --requestedExecutionDate → Body-Feld requestedExecutionDate, --betragCents → Body-Feld betragCents, --vorschlagHash → Body-Feld vorschlagHash
• Body: Pflicht (--data '<json>')

instandhaltung

casa instandhaltung list

Listet die Instandhaltungs-Vorgänge: "vorgangId", "nummer", "titel", "typSchluessel", "dringlichkeit" (sofort \| kurzfristig \| langfristig), "status" (gemeldet \| in_klaerung \| angebote_offen \| zur_freigabe \| freigegeben \| beauftragt \| ausgefuehrt \| abgerechnet \| abgeschlossen \| storniert) mit "statusSeit", "objekt", "einheit", "auftragswert" (Integer-String in Cent, null ohne lebenden Auftrag), "auftragsnummer" und "offeneBefunde". Optional --propertyId <uuid>, --status <wert[,wert]>, --dringlichkeit <wert[,wert]>, --typ <schluessel>, --nurOffen <true\|false> (ohne abgeschlossen und storniert), --limit (Vorgabe 50, höchstens 200) und --offset. Ohne Vorgänge ist die Liste leer. Nur lesend; zeigt nur Vorgänge der Objekte, für die der Aufrufer zuständig ist. Geld ist ein Integer-String in Cent.

casa instandhaltung list [--propertyId <wert>] [--status <wert>] [--dringlichkeit <wert>] [--typ <wert>] [--nurOffen <wert>] [--limit <wert>] [--offset <wert>]

• Endpunkt: GET /api/instandhaltung
• Token nötig: ja
• Query-Flags: --propertyId, --status, --dringlichkeit, --typ, --nurOffen, --limit, --offset
• Body: keiner

casa instandhaltung show

Zeigt EINEN Instandhaltungs-Vorgang: "status" mit "verlauf", "angebote", "auftraege", den Freigabestand des lebenden Auftrags ("freigabe": erforderliche, offene und abgelehnte Stufen), "rechnungen" mit Zahlungsstand ("zahlungsstand.stand": nicht-gebucht \| offen \| ausgeglichen, dazu nicht-ermittelbar, wenn der Buchungssatz keine lesbare Verbindlichkeit ist), die aktuellen "befunde" (Code, Schwere, Text) und die "naechsteSchritte". Optional --stichtag <JJJJ-MM-TT> (Vorgabe: Berliner Tag der Server-Uhr). Ein fremder, unbekannter oder nicht sichtbarer Vorgang ergibt "not_found". Nur lesend. Geld ist ein Integer-String in Cent.

casa instandhaltung show <id> [--stichtag <wert>]

• Endpunkt: GET /api/instandhaltung/{id}
• Token nötig: ja
• Argumente: <id> (exakte Stelligkeit — zu viele sind ebenfalls ein Bedienfehler)
• Query-Flags: --stichtag
• Body: keiner

casa instandhaltung katalog

Zeigt den Vorgangstypen-Katalog des Mandanten: "schluessel", "bezeichnung", "ohneAngebotErlaubt", "aktiv" und "vorgabe" (Typ aus der Vorgabe des Systems). Standardmäßig nur aktive Typen; --auchInaktive true zeigt alle. Nur lesend.

casa instandhaltung katalog [--auchInaktive <wert>]

• Endpunkt: GET /api/instandhaltung/katalog
• Token nötig: ja
• Query-Flags: --auchInaktive
• Body: keiner

casa instandhaltung einstellung

Zeigt die Instandhaltung-Einstellung des Mandanten: "zweitfreigabeAbCents" (Auftragswert, ab dem eine Zweitfreigabe nötig ist; null ⇒ nie), "vergleichsangeboteAbCents" (Integer-Strings in Cent), "mindestangebote" und "herkunft" (vorgabe \| mandant). Ohne gespeicherte Einstellung gilt die Vorgabe. Nur lesend.

casa instandhaltung einstellung

• Endpunkt: GET /api/instandhaltung/einstellung
• Token nötig: ja
• Body: keiner

casa instandhaltung aufgaben

Zeigt die offene Instandhaltung-Arbeit als Aufgaben: "aufgabeArt" (sofort-unbearbeitet \| angebot-ausstehend \| freigabe-wartet \| rechnung-fehlt), "ampel", "titel", "objektId", "frist" und "vorgangId". Optional --stichtag <JJJJ-MM-TT> (Vorgabe: Berliner Tag der Server-Uhr) und --propertyId <uuid>. Nur lesend; zeigt nur Vorgänge der Objekte, für die der Aufrufer zuständig ist.

casa instandhaltung aufgaben [--stichtag <wert>] [--propertyId <wert>]

• Endpunkt: GET /api/instandhaltung/aufgaben
• Token nötig: ja
• Query-Flags: --stichtag, --propertyId
• Body: keiner

casa instandhaltung einstellung setzen

Setzt die Instandhaltung-Einstellung des Mandanten. Braucht --data '{"zweitfreigabeAbCents":"500000","vergleichsangeboteAbCents":"100000","mindestangebote":3}' — Schwellen als Ziffern-String in Cent (zweitfreigabeAbCents null = nie), mindestangebote eine ganze Zahl. Nur ein Mensch mit Recht (sonst 403). Antwort: gesetzte Werte, "vorher" und "geaendert". Wiederholungssicher mit --idempotency-key.

casa instandhaltung einstellung setzen --data '<json>'

• Endpunkt: PUT /api/instandhaltung/einstellung
• Token nötig: ja
• Body: Pflicht (--data '<json>')

casa instandhaltung katalog setzen

Legt einen Vorgangstyp im Katalog des Mandanten an oder ändert ihn. Braucht --data '{"schluessel":"heizung","bezeichnung":"Heizung","ohneAngebotErlaubt":false,"aktiv":true}'. Nur ein Mensch mit Recht (sonst 403). Wiederholungssicher mit --idempotency-key.

casa instandhaltung katalog setzen --data '<json>'

• Endpunkt: PUT /api/instandhaltung/katalog
• Token nötig: ja
• Body: Pflicht (--data '<json>')

casa instandhaltung melden

Erfasst eine Meldung. Pflichtfelder in --data: propertyId (uuid), typSchluessel (aktiver Typ, siehe casa instandhaltung katalog), titel (1 bis 140 Zeichen), beschreibung (10 bis 5000 Zeichen), dringlichkeit (sofort \| kurzfristig \| langfristig). Optional unitId, melderPersonId, beginnAm (JJJJ-MM-TT), haeufigkeit, baulichVeraendernd. Beispiel: --data '{"propertyId":"<uuid>","typSchluessel":"schaden","titel":"Wasserschaden Bad","beschreibung":"Wasser tritt an der Decke aus.","dringlichkeit":"sofort"}'. Antwort: vorgangId, nummer, status gemeldet, naechsteSchritte, befunde. Ohne --data wird nichts gesendet. Wiederholungssicher mit --idempotency-key.

casa instandhaltung melden --data '<json>'

• Endpunkt: POST /api/instandhaltung
• Token nötig: ja
• Body: Pflicht (--data '<json>')

casa instandhaltung qualifizieren

Qualifiziert den Vorgang <id>: Typ, Dringlichkeit, baulich verändernd, Beginn und Häufigkeit oder ausdrücklich "beginnUnbekannt". Beispiel: --data '{"beginnAm":"2026-11-01","haeufigkeit":"täglich"}' oder --data '{"beginnUnbekannt":true}'. Aus gemeldet wird in_klaerung; ab angebote_offen sind die Angaben eingefroren (Konflikt). Antwort: status, naechsteSchritte, befunde, uebergang.

casa instandhaltung qualifizieren <id> --data '<json>'

• Endpunkt: POST /api/instandhaltung/{id}/qualifizieren
• Token nötig: ja
• Argumente: <id> (exakte Stelligkeit — zu viele sind ebenfalls ein Bedienfehler)
• Body: Pflicht (--data '<json>')

casa instandhaltung dienstleister

Weist dem Vorgang <id> einen Dienstleister zu (es entsteht ein Angebot im Status angefragt). Braucht --data '{"dienstleisterPersonId":"<uuid>"}'; die Person muss am Tag die Rolle dienstleister tragen (sonst 400). Derselbe Dienstleister zweimal ist ein Konflikt.

casa instandhaltung dienstleister <id> --data '<json>'

• Endpunkt: POST /api/instandhaltung/{id}/dienstleister
• Token nötig: ja
• Argumente: <id> (exakte Stelligkeit — zu viele sind ebenfalls ein Bedienfehler)
• Body: Pflicht (--data '<json>')

casa instandhaltung angebot

Erfasst das Angebot eines zugeordneten Dienstleisters für den Vorgang <id>. Beispiel: --data '{"dienstleisterPersonId":"<uuid>","betrag":{"cents":"120000","currency":"EUR"},"gueltigBis":"2026-12-31"}'. Geld ist ein Objekt {cents, currency} (Cent als Ziffern-String, currency EUR). Optional gueltigBis, realisierungAb (JJJJ-MM-TT), dokumentId.

casa instandhaltung angebot <id> --data '<json>'

• Endpunkt: POST /api/instandhaltung/{id}/angebot
• Token nötig: ja
• Argumente: <id> (exakte Stelligkeit — zu viele sind ebenfalls ein Bedienfehler)
• Body: Pflicht (--data '<json>')

casa instandhaltung angebot waehlen

Wählt ein vorliegendes Angebot des Vorgangs <id>. Braucht --data '{"angebotId":"<uuid>"}'. Antwort: das Angebot (Geld als {cents, currency}), anzahlAngebote und ein möglicher Befund (z. B. zu wenige Vergleichsangebote).

casa instandhaltung angebot waehlen <id> --data '<json>'

• Endpunkt: POST /api/instandhaltung/{id}/angebot/waehlen
• Token nötig: ja
• Argumente: <id> (exakte Stelligkeit — zu viele sind ebenfalls ein Bedienfehler)
• Body: Pflicht (--data '<json>')

casa instandhaltung angebot verwerfen

Verwirft ein Angebot des Vorgangs <id> mit Grund. Braucht --data '{"angebotId":"<uuid>","grund":"zu teuer"}' (grund 1 bis 200 Zeichen).

casa instandhaltung angebot verwerfen <id> --data '<json>'

• Endpunkt: POST /api/instandhaltung/{id}/angebot/verwerfen
• Token nötig: ja
• Argumente: <id> (exakte Stelligkeit — zu viele sind ebenfalls ein Bedienfehler)
• Body: Pflicht (--data '<json>')

casa instandhaltung freigabe beantragen

Beantragt die Kostenfreigabe des Vorgangs <id> (Auftrag im Status zur_freigabe). Beispiel: --data '{"angebotId":"<uuid>"}'; optional kostenobergrenze, dienstleisterPersonId, costCategoryId. Ohne Angebot nur bei Typen, die das erlauben. Geld ist ein Objekt {cents, currency} (Cent als Ziffern-String, currency EUR). Antwort: auftragId, version, betrag, stufen (verwalter \| zweit), zweitstufeNichtWirksam, befunde.

casa instandhaltung freigabe beantragen <id> --data '<json>'

• Endpunkt: POST /api/instandhaltung/{id}/freigabe
• Token nötig: ja
• Argumente: <id> (exakte Stelligkeit — zu viele sind ebenfalls ein Bedienfehler)
• Body: Pflicht (--data '<json>')

casa instandhaltung freigabe entscheiden

Entscheidet eine Stufe der Kostenfreigabe des Vorgangs <id>. Beispiel: --data '{"stufe":"verwalter","decision":"approved"}'; Ablehnung: --data '{"stufe":"verwalter","decision":"rejected","rejectReason":{"code":"zu-teuer"}}' (code: zu-teuer \| angebot-unklar \| beschluss-fehlt \| sonstiges, optional note). Eine zweite Stufe ("zweit") ist nur bei aktivem Vier-Augen-Schalter und erreichter Schwelle nötig. Wer den Antrag gestellt hat, darf bei aktivem Vier-Augen nicht selbst freigeben (403). Antwort: entschieden, auftragStatus, vorgangStatus, offeneStufen, ohneVierAugen.

casa instandhaltung freigabe entscheiden <id> --data '<json>'

• Endpunkt: POST /api/instandhaltung/{id}/freigabe/entscheid
• Token nötig: ja
• Argumente: <id> (exakte Stelligkeit — zu viele sind ebenfalls ein Bedienfehler)
• Body: Pflicht (--data '<json>')

casa instandhaltung auftrag erteilen

Erteilt den Auftrag des Vorgangs <id>, nachdem die Kostenfreigabe vollständig ist: ein Auftrag ohne gültige Freigabe wird nie erteilt (Konflikt). Beispiel: --data '{}' oder --data '{"auftragId":"<uuid>"}'. Optional auftragId; ohne Angabe gilt der lebende Auftrag des Vorgangs (keiner ⇒ not_found). Antwort: auftragId, auftragsnummer, erteiltAm und Befunde (Gestattung, Freistellung; sie sind Warnungen, die Erteilung läuft trotzdem).

casa instandhaltung auftrag erteilen <id> --data '<json>'

• Endpunkt: POST /api/instandhaltung/{id}/auftrag
• Token nötig: ja
• Argumente: <id> (exakte Stelligkeit — zu viele sind ebenfalls ein Bedienfehler)
• Body: Pflicht (--data '<json>')

casa instandhaltung ausfuehrung

Meldet die Ausführung des erteilten Auftrags des Vorgangs <id>. Beispiel: --data '{"ausgefuehrtAm":"2026-11-10","notiz":"Leitung ersetzt"}' (ausgefuehrtAm nicht nach heute und nicht vor der Erteilung; notiz optional, höchstens 500 Zeichen). Optional auftragId; ohne Angabe gilt der lebende Auftrag des Vorgangs (keiner ⇒ not_found). Antwort: auftragId und ausgefuehrtAm.

casa instandhaltung ausfuehrung <id> --data '<json>'

• Endpunkt: POST /api/instandhaltung/{id}/auftrag/ausfuehrung
• Token nötig: ja
• Argumente: <id> (exakte Stelligkeit — zu viele sind ebenfalls ein Bedienfehler)
• Body: Pflicht (--data '<json>')

casa instandhaltung auftrag stornieren

Storniert den Auftrag des Vorgangs <id> mit Grund. Beispiel: --data '{"grund":"Dienstleister abgesprungen"}' (grund 1 bis 200 Zeichen). Optional auftragId; ohne Angabe gilt der lebende Auftrag des Vorgangs (keiner ⇒ not_found). Nach der Freigabe fällt der Vorgang zurück in angebote_offen, eine neue Freigabe ist nötig. Antwort: auftragId und vorgangStatus.

casa instandhaltung auftrag stornieren <id> --data '<json>'

• Endpunkt: POST /api/instandhaltung/{id}/auftrag/stornieren
• Token nötig: ja
• Argumente: <id> (exakte Stelligkeit — zu viele sind ebenfalls ein Bedienfehler)
• Body: Pflicht (--data '<json>')

casa instandhaltung rechnung

Verknüpft den Rechnungsbeleg mit dem ausgeführten Auftrag des Vorgangs <id>. Beispiel: --data '{"documentId":"<uuid>","rechnungsdatum":"2026-11-10"}'. Optional auftragId; ohne Angabe gilt der lebende Auftrag des Vorgangs (keiner ⇒ not_found). Befunde sperren nicht, die Verknüpfung gelingt und nennt sie; die harte Sperre der Zahlung ohne Freistellungsbescheinigung liegt im Zahlungsauftrag. Exit 0, "befunde" mit Code, Schwere und Text (freistellung-fehlt, rechnung-ueber-auftrag, gestattungsbeschluss-fehlt). Geld ist ein Objekt {cents, currency}. Antwort: rechnungId, betrag, auftragswert, abweichung, summeRechnungen, bauleistung, befunde.

casa instandhaltung rechnung <id> --data '<json>'

• Endpunkt: POST /api/instandhaltung/{id}/rechnung
• Token nötig: ja
• Argumente: <id> (exakte Stelligkeit — zu viele sind ebenfalls ein Bedienfehler)
• Body: Pflicht (--data '<json>')

casa instandhaltung abschliessen

Schließt den Vorgang <id> ab. Beispiel: --data '{}' oder --data '{"begruendung":"Maßnahme erledigt"}' (begruendung optional, höchstens 300 Zeichen). Läuft noch ein Auftrag, ist das ein Konflikt. Antwort: vorgangId, vonStatus, status, ereignisId, begruendung.

casa instandhaltung abschliessen <id> --data '<json>'

• Endpunkt: POST /api/instandhaltung/{id}/abschluss
• Token nötig: ja
• Argumente: <id> (exakte Stelligkeit — zu viele sind ebenfalls ein Bedienfehler)
• Body: Pflicht (--data '<json>')

casa instandhaltung stornieren

Storniert den Vorgang <id> mit Grund. Beispiel: --data '{"grund":"Meldung irrtümlich"}' (grund 1 bis 200 Zeichen). Läuft noch ein Auftrag, ist das ein Konflikt. Antwort: vorgangId, vonStatus, status, ereignisId, begruendung.

casa instandhaltung stornieren <id> --data '<json>'

• Endpunkt: POST /api/instandhaltung/{id}/stornieren
• Token nötig: ja
• Argumente: <id> (exakte Stelligkeit — zu viele sind ebenfalls ein Bedienfehler)
• Body: Pflicht (--data '<json>')

fremdvertrag

casa fremdvertrag list

Listet die Verträge mit Dritten (Versicherung, Wartung, Dienstleistung, Versorgung): "id", "art", "bezeichnung", "partner", "beginn", "konditionen" zum Stichtag (Beitrag, Jahresbeitrag und Selbstbehalt als Integer-String in Cent), "fristen" (spaetesterZugang, aufgabeAb), "beendet" und "anzahlSchadenfaelle". Optional --propertyId <uuid>, --art <versicherung\|wartung\|dienstleistung\|versorgung>, --status <aktiv\|beendet\|alle> (Vorgabe aktiv), --limit (Vorgabe 50, höchstens 200) und --offset. Ohne Verträge ist die Liste leer. Nur lesend; zeigt nur Verträge der Objekte, für die der Aufrufer zuständig ist. Geld ist ein Integer-String in Cent.

casa fremdvertrag list [--propertyId <wert>] [--art <wert>] [--status <wert>] [--limit <wert>] [--offset <wert>]

• Endpunkt: GET /api/fremdvertrag
• Token nötig: ja
• Query-Flags: --propertyId, --art, --status, --limit, --offset
• Body: keiner

casa fremdvertrag show

Zeigt EINEN Vertrag mit Dritten: "vertrag" (Art, Bezeichnung, Partner, Objekt, Beginn), "konditionen" zum Stichtag und "historie", "ereignisse", den Fristenstand ("fristen": spaetesterZugang, aufgabeAb, verpasstesEnde, befunde), den Dauerzahlungs-Abgleich ("dauerzahlungAbgleich" mit Befund beitrag-weicht-von-dauerzahlung-ab) und die "schadenfaelle". Optional --stichtag <JJJJ-MM-TT> (Vorgabe: Berliner Tag der Server-Uhr). Ein fremder, unbekannter oder nicht sichtbarer Vertrag ergibt "not_found". Nur lesend. Geld ist ein Integer-String in Cent.

casa fremdvertrag show <id> [--stichtag <wert>]

• Endpunkt: GET /api/fremdvertrag/{id}
• Token nötig: ja
• Argumente: <id> (exakte Stelligkeit — zu viele sind ebenfalls ein Bedienfehler)
• Query-Flags: --stichtag
• Body: keiner

casa fremdvertrag fristen

Zeigt den Fristenwächter der Verträge mit Dritten: je Zeile "kategorie" (kuendigungsfrist \| frist-verpasst \| ohne-laufzeit), "spaetesterZugang" (letzter Tag, an dem die Kündigung zugehen muss), "aufgabeAb", "tageBisFrist" (negativ, wenn verstrichen), "ampel", "vertragsende", "refId" (der Vertrag) und "offen". Optional --stichtag <JJJJ-MM-TT> (Vorgabe: Berliner Tag der Server-Uhr), --propertyId <uuid>, --art <versicherung\|wartung\|dienstleistung\|versorgung>, --nurOffen <true\|false> (Vorgabe true: nur Handlungsbedarf) und --mitUeberwachungsluecken <true\|false> (Verträge ohne Laufzeitende, Kategorie ohne-laufzeit). Ohne Fristen ist die Liste leer. Nur lesend, keine Aktion, keine Mail; zeigt nur Verträge der Objekte, für die der Aufrufer zuständig ist.

casa fremdvertrag fristen [--stichtag <wert>] [--propertyId <wert>] [--art <wert>] [--nurOffen <wert>] [--mitUeberwachungsluecken <wert>]

• Endpunkt: GET /api/fremdvertrag/fristen
• Token nötig: ja
• Query-Flags: --stichtag, --propertyId, --art, --nurOffen, --mitUeberwachungsluecken
• Body: keiner

casa fremdvertrag einstellung

Zeigt die Einstellung der Verträge mit Dritten: "vorlaufTage" (Aufgabe ab Zugangstermin minus Vorlauf), "verlaengerungStillschweigendVorgabe", "verlaengerungMonateVorgabe", "schadenMeldefristTage", "schadenhonorarProzentBp" (Basispunkte), "schadenhonorarProzentText", "schadenhonorarAktiv" und "herkunft" (vorgabe \| mandant). Ohne gespeicherte Einstellung gilt die Vorgabe. Nur lesend.

casa fremdvertrag einstellung

• Endpunkt: GET /api/fremdvertrag/einstellung
• Token nötig: ja
• Body: keiner

casa fremdvertrag anlegen

Legt einen Vertrag mit Dritten samt ersten Konditionen an. Beispiel: --data '{"propertyId":"<uuid>","art":"wartung","partnerPersonId":"<uuid>","bezeichnung":"Aufzugswartung","beginn":"2026-01-01","laufzeitEnde":"2026-12-31","kuendigungsfristMonate":3,"beitrag":{"cents":"30000","currency":"EUR"},"beitragIntervall":"quartalsweise"}' (art: versicherung \| wartung \| dienstleistung \| versorgung; Partner mit Rolle Kreditor oder Dienstleister; optional vertragsnummer, selbstbehalt nur bei Versicherung, bemerkung). Ohne Angabe zur Verlängerung gilt: ja, 12 Monate (oder die Vorgabe der Einstellung). Geld ist ein Objekt {cents, currency}. Antwort: vertragId und konditionen (Version 1). Wiederholungssicher mit --idempotency-key.

casa fremdvertrag anlegen --data '<json>'

• Endpunkt: POST /api/fremdvertrag
• Token nötig: ja
• Body: Pflicht (--data '<json>')

casa fremdvertrag konditionen

Legt eine neue Konditions-Version für den Vertrag <id> an (kein Teil-Patch: jeder Schlüssel ist Pflicht, leer ist null). Beispiel: --data '{"gueltigAb":"2027-01-01","laufzeitEnde":"2027-12-31","kuendigungsfristMonate":3,"verlaengerungStillschweigend":true,"verlaengerungMonate":12,"beitrag":{"cents":"32000","currency":"EUR"},"beitragIntervall":"quartalsweise","selbstbehalt":null,"bemerkung":null}'. gueltigAb muss nach der letzten Version liegen. Geld ist ein Objekt {cents, currency}. Antwort: vertragId und konditionen (neue Version).

casa fremdvertrag konditionen <id> --data '<json>'

• Endpunkt: POST /api/fremdvertrag/{id}/konditionen
• Token nötig: ja
• Argumente: <id> (exakte Stelligkeit — zu viele sind ebenfalls ein Bedienfehler)
• Body: Pflicht (--data '<json>')

casa fremdvertrag kuendigen

Hält die Kündigung des Vertrags <id> fest. Beispiel: --data '{"wirksamZum":"2026-12-31","grund":"Anbieterwechsel"}' (wirksamZum nicht vor heute; grund optional, höchstens 200 Zeichen). Die Antwort nennt das früheste Vertragsende ("fruehestesEnde") und den spätesten Zugang ("spaetesterZugang") als Auskunft; sie sperrt nicht. Antwort: vertragId, ereignisId, wirksamZum, fruehestesEnde, spaetesterZugang.

casa fremdvertrag kuendigen <id> --data '<json>'

• Endpunkt: POST /api/fremdvertrag/{id}/kuendigung
• Token nötig: ja
• Argumente: <id> (exakte Stelligkeit — zu viele sind ebenfalls ein Bedienfehler)
• Body: Pflicht (--data '<json>')

casa fremdvertrag beenden

Beendet den Vertrag <id>. Beispiel: --data '{"beendetAm":"2026-12-31","grund":"Vertragsende"}' (beendetAm nicht vor dem Beginn; grund optional, höchstens 200 Zeichen). Es gibt kein Löschen: ein beendeter Vertrag bleibt lesbar. Antwort: vertragId, ereignisId, beendetAm.

casa fremdvertrag beenden <id> --data '<json>'

• Endpunkt: POST /api/fremdvertrag/{id}/beendigung
• Token nötig: ja
• Argumente: <id> (exakte Stelligkeit — zu viele sind ebenfalls ein Bedienfehler)
• Body: Pflicht (--data '<json>')

casa fremdvertrag frist entscheiden

Hält die Entscheidung zu einem Vertragsende des Vertrags <id> fest. Beispiel: --data '{"bezugEnde":"2026-12-31","entscheidung":"verlaengern","grund":"Konditionen passen"}' (entscheidung: verlaengern \| kuendigen \| neu_ausschreiben; grund optional). Danach verschwindet die Zeile aus "fremdvertrag fristen". Es wird nie eine Kündigung angelegt — die schreibt "fremdvertrag kuendigen". Antwort: vertragId, bezugEnde, entscheidung, ereignisId, kuendigungAngelegt (false), hinweis.

casa fremdvertrag frist entscheiden <id> --data '<json>'

• Endpunkt: POST /api/fremdvertrag/{id}/frist-entscheid
• Token nötig: ja
• Argumente: <id> (exakte Stelligkeit — zu viele sind ebenfalls ein Bedienfehler)
• Body: Pflicht (--data '<json>')

casa fremdvertrag dauerzahlung

Verknüpft den Vertrag <id> mit einer Dauerzahlung desselben Objekts. Beispiel: --data '{"dauerzahlungId":"<uuid>"}'. Weichen Beitrag und Dauerzahlung ab, steht in der Antwort der "befund" (beitragJahr, dauerzahlungJahr, differenz); er sperrt nicht, Exit 0. Geld ist ein Objekt {cents, currency}. Antwort: vertragId, dauerzahlungId, befund (null ohne Abweichung).

casa fremdvertrag dauerzahlung <id> --data '<json>'

• Endpunkt: POST /api/fremdvertrag/{id}/dauerzahlung
• Token nötig: ja
• Argumente: <id> (exakte Stelligkeit — zu viele sind ebenfalls ein Bedienfehler)
• Body: Pflicht (--data '<json>')

casa fremdvertrag dauerzahlung loesen

Löst die Verknüpfung des Vertrags <id> mit seiner Dauerzahlung. Beispiel: --data '{}'. Die Dauerzahlung selbst bleibt unberührt. Antwort: vertragId und dauerzahlungId (die bis eben verknüpfte).

casa fremdvertrag dauerzahlung loesen <id> --data '<json>'

• Endpunkt: POST /api/fremdvertrag/{id}/dauerzahlung/loesen
• Token nötig: ja
• Argumente: <id> (exakte Stelligkeit — zu viele sind ebenfalls ein Bedienfehler)
• Body: Pflicht (--data '<json>')

casa fremdvertrag einstellung setzen

Setzt die Einstellung der Verträge mit Dritten des Mandanten (alle sechs Werte, kein Teil-Patch). Braucht --data '{"vorlaufTage":90,"verlaengerungStillschweigendVorgabe":true,"verlaengerungMonateVorgabe":12,"schadenMeldefristTage":7,"schadenhonorarProzentBp":800,"schadenhonorarAktiv":true}' — vorlaufTage 1 bis 365, Verlängerung 1 bis 60 Monate, Meldefrist 1 bis 60 Tage, Schadenhonorar in Basispunkten (800 = 8,00 %). Nur ein Mensch mit dem Recht, Rollen und Rechte zu verwalten (sonst Exit 403). Antwort: einstellung, vorher, geaendert, geaendertVon, geaendertAm. Wiederholungssicher mit --idempotency-key.

casa fremdvertrag einstellung setzen --data '<json>'

• Endpunkt: PUT /api/fremdvertrag/einstellung
• Token nötig: ja
• Body: Pflicht (--data '<json>')

schadenfall

casa schadenfall list

Listet die Schadenfälle: "id", "nummer", "status" (erfasst \| gemeldet \| deckung_zugesagt \| deckung_abgelehnt \| reguliert \| abgeschlossen), "schadensdatum", "schadenart", "objekt", "schadenssumme" (Integer-String in Cent, null, wenn unbekannt) und "anzahlBefunde". Optional --propertyId <uuid>, --status <wert[,wert]>, --versicherungsvertragId <uuid>, --instandhaltungVorgangId <uuid>, --nurOffen <true\|false> (ohne abgeschlossen), --limit (Vorgabe 50, höchstens 200) und --offset. Ohne Schadenfälle ist die Liste leer. Nur lesend; zeigt nur Fälle der Objekte, für die der Aufrufer zuständig ist. Geld ist ein Integer-String in Cent.

casa schadenfall list [--propertyId <wert>] [--status <wert>] [--versicherungsvertragId <wert>] [--instandhaltungVorgangId <wert>] [--nurOffen <wert>] [--limit <wert>] [--offset <wert>]

• Endpunkt: GET /api/schadenfall
• Token nötig: ja
• Query-Flags: --propertyId, --status, --versicherungsvertragId, --instandhaltungVorgangId, --nurOffen, --limit, --offset
• Body: keiner

casa schadenfall show

Zeigt EINEN Schadenfall: "schadenfall" (Status, Schadensdatum, Schadenart, Selbstbehalt, Schadenssumme), "versicherungsvertrag", "instandhaltungVorgang", die "befunde" (meldefrist-verstrichen \| schaden-ausserhalb-laufzeit \| versicherung-fehlt \| erstattung-weicht-ab), die "bilanz" (Schadenssumme, Selbstbehalt, erwartete Erstattung, erstattet, Differenz), die "erstattungen" mit Buchungsstand (gebucht \| vorgeschlagen) und den "honorar"-Vorschlag; der Honorar-Vorschlag wird nicht automatisch abgerechnet. Optional --stichtag <JJJJ-MM-TT> (Vorgabe: Berliner Tag der Server-Uhr). Ein fremder, unbekannter oder nicht sichtbarer Schadenfall ergibt "not_found". Nur lesend. Geld ist ein Integer-String in Cent.

casa schadenfall show <id> [--stichtag <wert>]

• Endpunkt: GET /api/schadenfall/{id}
• Token nötig: ja
• Argumente: <id> (exakte Stelligkeit — zu viele sind ebenfalls ein Bedienfehler)
• Query-Flags: --stichtag
• Body: keiner

casa schadenfall anlegen

Erfasst einen Schadenfall (Status erfasst). Beispiel: --data '{"propertyId":"<uuid>","schadensdatum":"2026-11-01","schadenart":"Wasserschaden","beschreibung":"Rohrbruch im Keller, Wasser steht 5 cm hoch.","versicherungsvertragId":"<uuid>","instandhaltungVorgangId":"<uuid>"}' (schadensdatum nicht nach heute; beschreibung 10 bis 5000 Zeichen; optional unitId, versicherungsvertragId, instandhaltungVorgangId, jeweils desselben Objekts). Antwort: schadenfallId, nummer, status, selbstbehalt und befunde.

casa schadenfall anlegen --data '<json>'

• Endpunkt: POST /api/schadenfall
• Token nötig: ja
• Body: Pflicht (--data '<json>')

casa schadenfall melden

Hält die Meldung des Schadenfalls <id> an den Versicherer fest. Beispiel: --data '{"gemeldetAm":"2026-11-03","aktenzeichen":"AZ-4711"}' (gemeldetAm nicht nach heute und nicht vor dem Schadensdatum; optional versicherungsvertragId, wenn dem Fall noch keine Versicherung zugeordnet ist). Eine verstrichene Meldefrist warnt als Befund (meldefrist-verstrichen), aber die Meldung wird festgehalten, Exit 0. Antwort: schadenfallId, nummer, status (gemeldet), selbstbehalt, befunde.

casa schadenfall melden <id> --data '<json>'

• Endpunkt: POST /api/schadenfall/{id}/meldung
• Token nötig: ja
• Argumente: <id> (exakte Stelligkeit — zu viele sind ebenfalls ein Bedienfehler)
• Body: Pflicht (--data '<json>')

casa schadenfall deckung

Erfasst die Deckungsentscheidung des Versicherers für den Schadenfall <id>. Beispiel: --data '{"entscheidung":"zugesagt","deckungAm":"2026-11-05","schadenssumme":{"cents":"500000","currency":"EUR"},"selbstbehalt":{"cents":"50000","currency":"EUR"}}' (entscheidung: zugesagt \| abgelehnt; deckungAm nicht nach heute und nicht vor der Meldung). Geld ist ein Objekt {cents, currency}. Antwort: schadenfallId, nummer, status, selbstbehalt, schadenssumme, uebergang, befunde.

casa schadenfall deckung <id> --data '<json>'

• Endpunkt: POST /api/schadenfall/{id}/deckung
• Token nötig: ja
• Argumente: <id> (exakte Stelligkeit — zu viele sind ebenfalls ein Bedienfehler)
• Body: Pflicht (--data '<json>')

casa schadenfall erstattung

Ordnet einen Bankumsatz als Erstattung dem Schadenfall <id> zu. Beispiel: --data '{"bankAccountId":"<uuid>","bankTransactionId":"<uuid>","asOf":"2026-11-06","bankGlAccountNo":"1200","sachkontoNo":"4260","buchungstext":"Erstattung Gebäudeversicherung"}'. Die Buchung entsteht als Vorschlag und wird erst nach der Freigabe gebucht. Der Fall muss auf Deckung zugesagt oder reguliert stehen; ein Umsatz gehört höchstens einem Schadenfall. Antwort: schadenfallId, status, erstattung, bilanz (Integer-Strings in Cent), vorschlag.

casa schadenfall erstattung <id> --data '<json>'

• Endpunkt: POST /api/schadenfall/{id}/erstattung
• Token nötig: ja
• Argumente: <id> (exakte Stelligkeit — zu viele sind ebenfalls ein Bedienfehler)
• Body: Pflicht (--data '<json>')

casa schadenfall abschliessen

Schließt den Schadenfall <id> ab. Beispiel: --data '{}' oder --data '{"begruendung":"Fall erledigt"}' (begruendung optional, höchstens 300 Zeichen; ohne Versicherungsbezug Pflicht). Antwort: schadenfallId, vonStatus, status, begruendung, bilanz, befund.

casa schadenfall abschliessen <id> --data '<json>'

• Endpunkt: POST /api/schadenfall/{id}/abschluss
• Token nötig: ja
• Argumente: <id> (exakte Stelligkeit — zu viele sind ebenfalls ein Bedienfehler)
• Body: Pflicht (--data '<json>')

mieterhoehung

casa mieterhoehung staffelliste

Zeigt die Staffelmieterhöhungsliste: je Vertrag mit mindestens einem Kaltmieten-Wechsel die zum Stichtag geltende ("aktuell") und die unmittelbar vorherige Kaltmiete ("vorher") mit Gültigkeitsbeginn ("gueltigAb"), die Differenz ("differenzCents", Integer-STRING in Cent), die nächste künftige Stufe ("naechste") und die Herkunft des Wechsels ("herkunft": "anlage" = im Anlage-Kommando des Vertrags entstanden, sonst "konditionswechsel"). Optional --stichtag <JJJJ-MM-TT> (Vorgabe: heute, Server-Uhr), --von/--bis <JJJJ-MM-TT> (nur Verträge, deren aktuelle Stufe in diesem Zeitraum gültig wurde) und --objekt <uuid>. Nur lesend; zeigt nur Verträge der Objekte, für die der Aufrufer zuständig ist.

casa mieterhoehung staffelliste [--stichtag <wert>] [--von <wert>] [--bis <wert>] [--objekt <wert>]

• Endpunkt: GET /api/mieterhoehung/staffelliste
• Token nötig: ja
• Query-Flags: --stichtag, --von, --bis, --objekt
• Body: keiner

casa mieterhoehung faellig

Zeigt je laufendem Wohnraumvertrag, wer für eine Mieterhöhung fällig ist: "paragraph558" (frühester Termin aus der Jahressperrfrist = letzte Erhöhung + 12 Monate, "status" faellig \| noch-nicht-faellig \| gesperrt; gesperrt mit "grund" bei Index- oder Staffelvereinbarung), bei Indexmiete "paragraph557b" (frühester Anpassungstermin, "juengsterVpiMonat" und die neue Miete "neueKaltmieteCents" als Vorschau, Integer-STRING in Cent; "vpi-fehlt" bzw. "basisjahr-abweichend" statt eines geschätzten oder umgerechneten Werts) und "offenerVorgang" mit dem Ende der Zustimmungsfrist eines versendeten Vorgangs. Optional --stichtag <JJJJ-MM-TT> (Vorgabe: heute, Server-Uhr). Nur lesend — kein Vorgang, keine Mail; Gewerbeverträge erscheinen nicht; zeigt nur Verträge der Objekte, für die der Aufrufer zuständig ist.

casa mieterhoehung faellig [--stichtag <wert>]

• Endpunkt: GET /api/mieterhoehung/faellig
• Token nötig: ja
• Query-Flags: --stichtag
• Body: keiner

casa mieterhoehung anlegen

Legt ein Mieterhöhungsverlangen nach § 558 BGB für einen Vertrag an: Vorgang im Zustand "entwurf" plus dokumentiertes Schreiben, der Vorgang erscheint in der Freigabe — es entsteht KEINE Zeitscheibe (umgestellt wird erst nach "mieterhoehung entscheiden" ... approved über die Konditionen). Braucht <vertragId> und --data '{"wirksamAb":"2027-01-01","zugangAm":"2026-10-01","neueKaltmieteCents":"90000","currency":"EUR","vergleichsmieteCents":"95000","gebiet":"regel","laufendeVereinbarung":"keine","payments":[],"begruendung":{"weg":"mietdatenbank","bezeichnung":"Mietdatenbank Beispielstadt","standJahr":2025},"verwaltung":{"art":"eigenverwaltung"}}' — Cent-Felder sind Integer-STRINGS; "payments" ist Pflicht (auch leer); "begruendung.weg": qualifizierter-mietspiegel \| einfacher-mietspiegel \| mietdatenbank \| vergleichswohnungen \| sachverstaendigengutachten. Antwort: mieterhoehungId, schreibenId, zustimmungsfristBis. Kappungsgrenze/Jahressperrfrist verletzt ⇒ 409 MIETERHOEHUNG_UNZULAESSIG; schon ein Verlangen zu dem Tag ⇒ 409 MIETERHOEHUNG_DOPPELT; Wucher ⇒ 422 MIETERHOEHUNG_WUCHER; Begründung trägt nicht ⇒ 422 MIETERHOEHUNG_SCHREIBEN_UNGUELTIG; Tag vor Ende der Zustimmungsfrist ⇒ 422 MIETERHOEHUNG_VOR_ZUSTIMMUNGSFRIST; Tag in der Vergangenheit ⇒ 422 MIETERHOEHUNG_RUECKWIRKEND; fremder/unbekannter Vertrag ⇒ 404. Bei einer Abweisung wird nichts geschrieben. Ein tenantId/contractId im Body wird ignoriert.

casa mieterhoehung anlegen <id> --data '<json>'

• Endpunkt: POST /api/vertrag/{id}/mieterhoehung
• Token nötig: ja
• Argumente: <id> (exakte Stelligkeit — zu viele sind ebenfalls ein Bedienfehler)
• Body: Pflicht (--data '<json>')

casa mieterhoehung entscheiden

Entscheidet EINE Mieterhöhungs-Fassung: <mieterhoehungId> plus --data '{"decision":"approved"}' (freigeben) oder '{"decision":"rejected","reasonCode":"falscher-betrag"}' (ablehnen; Grund Pflicht: falscher-betrag \| falscher-kreditor \| falsche-kontierung \| kein-beleg \| doppelt \| nicht-plausibel \| sonstiges; bei approved verboten). Bindung und Inhalts-Hash bestimmt der Server selbst — der Body trägt keinen Hash. Verlangt eine frische Anmeldung (sonst 403). Ein Agent darf nicht entscheiden (403, nichts geschrieben); fremde/unbekannte Fassung ⇒ 404; verfallene oder schon entschiedene Fassung ⇒ 409.

casa mieterhoehung entscheiden <id> [--decision <wert>] [--reasonCode <wert>] --data '<json>'

• Endpunkt: POST /api/mieterhoehung/{id}/entscheidung
• Token nötig: ja
• Argumente: <id> (exakte Stelligkeit — zu viele sind ebenfalls ein Bedienfehler)
• Body-Flags: --decision → Body-Feld decision, --reasonCode → Body-Feld reasonCode
• Body: Pflicht (--data '<json>')

casa mieterhoehung feststellen

Stellt die Reaktion des Mieters auf ein Erhöhungsverlangen fest: <mieterhoehungId> plus --art zustimmung-ausdruecklich\|widerspruch\|sonderkuendigung und --festgestellt-am YYYY-MM-DD (oder --data). Zustimmung ⇒ Zustand "wirksam", Widerspruch/Sonderkündigung ⇒ "abgelehnt". Setzt einen Zustellnachweis voraus (sonst 409), fällt genau einmal (zweite Feststellung 409); ein Agent darf das nie (403). Der Erfasser ist der angemeldete Mensch.

casa mieterhoehung feststellen <id> [--art <wert>] [--festgestellt-am <wert>] --data '<json>'

• Endpunkt: POST /api/mieterhoehung/{id}/feststellung
• Token nötig: ja
• Argumente: <id> (exakte Stelligkeit — zu viele sind ebenfalls ein Bedienfehler)
• Body-Flags: --art → Body-Feld art, --festgestellt-am → Body-Feld festgestelltAm
• Body: Pflicht (--data '<json>')

casa mieterhoehung zahlung

Erfasst eine beobachtete Zahlung zum Erhöhungsverlangen: <mieterhoehungId> plus --data '{"zahlungEntryId":"<uuid>","periode":"2026-03","unterVorbehalt":false}'. "unterVorbehalt" ist PFLICHT (true\|false, kein Default) — "vorbehaltlos" bestätigt ein Mensch, es wird nie aus dem Bank-Matching abgeleitet. Betrag, Währung und Datum liest der Server aus dem Buchungssatz, der eine Zahlung auf dem Mieter-Personenkonto dieses Vertrags sein muss (sonst 404). Die dritte vorbehaltlose Zahlung in drei Perioden stellt die konkludente Zustimmung fest; eine Zahlung unter Vorbehalt zählt nicht. Ohne Zustellnachweis 409.

casa mieterhoehung zahlung <id> --data '<json>'

• Endpunkt: POST /api/mieterhoehung/{id}/zahlung
• Token nötig: ja
• Argumente: <id> (exakte Stelligkeit — zu viele sind ebenfalls ein Bedienfehler)
• Body: Pflicht (--data '<json>')

casa mieterhoehung zuruecknehmen

Nimmt eine wirksame Mieterhöhung zurück: <mieterhoehungId> plus --zurueckgenommen-am YYYY-MM-DD und --begruendung "<Text>" (Pflicht; oder --data). Zustand "zurueckgenommen"; die Antwort nennt "alterBetragCents", den Betrag, der wieder gilt. Nicht wirksam ⇒ 409; ein Agent darf das nie (403).

casa mieterhoehung zuruecknehmen <id> [--zurueckgenommen-am <wert>] [--begruendung <wert>] --data '<json>'

• Endpunkt: POST /api/mieterhoehung/{id}/ruecknahme
• Token nötig: ja
• Argumente: <id> (exakte Stelligkeit — zu viele sind ebenfalls ein Bedienfehler)
• Body-Flags: --zurueckgenommen-am → Body-Feld zurueckgenommenAm, --begruendung → Body-Feld begruendung
• Body: Pflicht (--data '<json>')

casa mieterhoehung indexerklaerung

Erzeugt die Erklärung einer Indexanpassung nach § 557b Abs. 3 BGB als Text im Standardwortlaut: <mieterhoehungId> eines Index-Vorgangs. Die Antwort trägt "text" (alter und neuer Index, alte und neue Miete, Rechenweg, Wirksamkeitsmonat = Beginn des übernächsten Monats nach dem Zugang), "vorlageVersion", "dokumentHash" (SHA-256 hex über den Text) und "zugangErfasst" (false = kein Zugangstag erfasst, der Wirksamkeitsmonat ist die Vorschau aus dem geplanten Wirksamkeitstag). Indexwerte und Betrag kommen aus dem gespeicherten Vorgang und werden nachgerechnet; weicht das ab ⇒ 409, kein Text. Ein § 558-Vorgang ⇒ 409 MIETERHOEHUNG_KEIN_INDEXVORGANG; fremder oder unbekannter Vorgang ⇒ 404. Nur lesend — der Text wird erzeugt, nicht versendet.

casa mieterhoehung indexerklaerung <id>

• Endpunkt: GET /api/mieterhoehung/{id}/indexerklaerung
• Token nötig: ja
• Argumente: <id> (exakte Stelligkeit — zu viele sind ebenfalls ein Bedienfehler)
• Body: keiner

casa mieterhoehung versenden

Versendet das freigegebene Mieterhöhungsschreiben (§ 558a BGB): <mieterhoehungId> plus --versandweg mail\|druck (mail über den Versandkanal des Mandanten, druck protokolliert nur die Übergabe) und --data '{}' (bei Ein-Personen-Mandanten --data '{"selbstfreigabeBestaetigt":true}'). Ergebnis: ausgang "zugestellt" (Zustellnachweis mit Dokument-Hash, Zustand "versendet" — nicht "wirksam") oder "fehlgeschlagen" mit fehlerCode (Zustand unverändert, erneut versendbar). Verlangt Freigabe durch eine andere Person und eine frische Anmeldung (sonst 403 MIETERHOEHUNG_VERSAND_GESPERRT, nichts versendet); ein Agent darf nicht versenden (403); schon zugegangen ⇒ 409 MIETERHOEHUNG_BEREITS_VERSENDET; fremder/unbekannter Vorgang ⇒ 404. Akteurs-Kette und Anmeldung bestimmt der Server, nie der Body.

casa mieterhoehung versenden <id> [--versandweg <wert>] --data '<json>'

• Endpunkt: POST /api/mieterhoehung/{id}/versand
• Token nötig: ja
• Argumente: <id> (exakte Stelligkeit — zu viele sind ebenfalls ein Bedienfehler)
• Body-Flags: --versandweg → Body-Feld versandweg
• Body: Pflicht (--data '<json>')

mahnlauf

casa mahnlauf list

Zeigt die offenen Mahnlauf-Vorgänge (fällig oder in Arbeit) der Objekte, für die der Aufrufer zuständig ist, den Vorgang, den das Register öffnet ("gewaehlt"; --lauf <vorgangId> ist der Deep-Link), die früheren (ausgeführten) Vorgänge und — ohne offenen Vorgang — "zuMahnendeDebitoren". Ein Vorgang gehört dem, der ihn bearbeitet ("inArbeitBei", "fremdInArbeit"). Nur lesend — nichts davon mahnt.

casa mahnlauf list [--lauf <wert>]

• Endpunkt: GET /api/mahnlauf
• Token nötig: ja
• Query-Flags: --lauf
• Body: keiner

casa mahnlauf show

Zeigt EINEN Mahnlauf-Vorgang: Kopf (Stichtag, Status, Schritt, Summen, wer ihn bearbeitet), Umfang (Objekte und Einheiten der Zuständigkeit), die Positionen mit "schluessel" (für ausschliessen/zurueckholen) und Beträgen als Integer-STRINGS in Cent, bei einem ausgeführten Vorgang das Ergebnis. Fremder oder unbekannter Vorgang ⇒ dieselbe 404. Nur lesend — nichts davon mahnt.

casa mahnlauf show <id>

• Endpunkt: GET /api/mahnlauf/{id}
• Token nötig: ja
• Argumente: <id> (exakte Stelligkeit — zu viele sind ebenfalls ein Bedienfehler)
• Body: keiner

casa mahnlauf starten

Startet einen Mahnlauf-Vorgang oder öffnet den eigenen, schon vorbereiteten: --stichtag <JJJJ-MM-TT> (Pflicht), --automatisch (Schalter, Vorgabe aus). Ein zweiter Aufruf desselben Nutzers zum selben Stichtag öffnet denselben Vorgang ("neu": false) und legt keinen zweiten an. Ein Vorgang gehört dem, der ihn bearbeitet: ist er bei jemand anderem in Arbeit, ist er nur anzusehen — nichts geschrieben. Ein ausgeführter Vorgang ist nicht mehr änderbar. Ein Objekt, das ein anderer offener Vorgang hält, ist im Umfang nicht wählbar. Ausführen, Freigabe und Versand folgen in einem eigenen Schritt — nichts davon mahnt schon.

casa mahnlauf starten [--stichtag <wert>] [--automatisch] --data '<json>'

• Endpunkt: POST /api/mahnlauf
• Token nötig: ja
• Body-Flags: --stichtag → Body-Feld stichtag, --automatisch → Body-Feld automatisch
• Body: Pflicht (--data '<json>')

casa mahnlauf stichtag

Setzt den Stichtag eines Vorgangs: <vorgangId> --stichtag <JJJJ-MM-TT>. Ein Vorgang gehört dem, der ihn bearbeitet: ist er bei jemand anderem in Arbeit, ist er nur anzusehen — nichts geschrieben. Ein ausgeführter Vorgang ist nicht mehr änderbar. Ein Objekt, das ein anderer offener Vorgang hält, ist im Umfang nicht wählbar. Nichts davon mahnt schon.

casa mahnlauf stichtag <id> [--stichtag <wert>] --data '<json>'

• Endpunkt: PATCH /api/mahnlauf/{id}
• Token nötig: ja
• Argumente: <id> (exakte Stelligkeit — zu viele sind ebenfalls ein Bedienfehler)
• Body-Flags: --stichtag → Body-Feld stichtag
• Body: Pflicht (--data '<json>')

casa mahnlauf umfang

Setzt den Umfang eines Vorgangs: <vorgangId> --data '{"objektIds":["<uuid>"],"abgewaehlteEinheitIds":[]}' — die Objekte im Umfang und die abgewählten Einheiten (beide Listen Pflicht, ggf. leer). Gewählt werden können nur Objekte, für die der Aufrufer zuständig ist. Ein Vorgang gehört dem, der ihn bearbeitet: ist er bei jemand anderem in Arbeit, ist er nur anzusehen — nichts geschrieben. Ein ausgeführter Vorgang ist nicht mehr änderbar. Ein Objekt, das ein anderer offener Vorgang hält, ist im Umfang nicht wählbar. Nichts davon mahnt schon.

casa mahnlauf umfang <id> --data '<json>'

• Endpunkt: PATCH /api/mahnlauf/{id}
• Token nötig: ja
• Argumente: <id> (exakte Stelligkeit — zu viele sind ebenfalls ein Bedienfehler)
• Body: Pflicht (--data '<json>')

casa mahnlauf schritt

Merkt den Schritt (0 bis 3) eines Vorgangs: <vorgangId> --schritt <0..3>. Ein Schritt über 0 nimmt den Vorgang in Arbeit — ab da gehört er dem Aufrufer. Ein Vorgang gehört dem, der ihn bearbeitet: ist er bei jemand anderem in Arbeit, ist er nur anzusehen — nichts geschrieben. Ein ausgeführter Vorgang ist nicht mehr änderbar. Ein Objekt, das ein anderer offener Vorgang hält, ist im Umfang nicht wählbar. Nichts davon mahnt schon.

casa mahnlauf schritt <id> [--schritt <wert>] --data '<json>'

• Endpunkt: PATCH /api/mahnlauf/{id}
• Token nötig: ja
• Argumente: <id> (exakte Stelligkeit — zu viele sind ebenfalls ein Bedienfehler)
• Body-Flags: --schritt → Body-Feld schritt
• Body: Pflicht (--data '<json>')

casa mahnlauf ausschliessen

Nimmt eine Position aus dem Mahnlauf: <vorgangId> --position <schluessel> (aus "mahnlauf show") --grund "<Text>" (Pflicht, höchstens 200 Zeichen). Ohne Grund wird nichts gesendet. Erneutes Ausschließen lässt eine Zeile stehen (der jüngere Grund gilt); der Grund steht nicht in der Antwort. Ein Vorgang gehört dem, der ihn bearbeitet: ist er bei jemand anderem in Arbeit, ist er nur anzusehen — nichts geschrieben. Ein ausgeführter Vorgang ist nicht mehr änderbar. Ein Objekt, das ein anderer offener Vorgang hält, ist im Umfang nicht wählbar. Nichts davon mahnt schon.

casa mahnlauf ausschliessen <id> [--position <wert>] [--grund <wert>] --data '<json>'

• Endpunkt: POST /api/mahnlauf/{id}/ausschluss
• Token nötig: ja
• Argumente: <id> (exakte Stelligkeit — zu viele sind ebenfalls ein Bedienfehler)
• Body-Flags: --position → Body-Feld positionsSchluessel, --grund → Body-Feld grund
• Body: Pflicht (--data '<json>')

casa mahnlauf zurueckholen

Holt eine ausgeschlossene Position in den Mahnlauf zurück: <vorgangId> --position <schluessel>. Gab es keinen Ausschluss, ist das ein Erfolg ohne Wirkung ("zurueckgeholt": false). Ein Vorgang gehört dem, der ihn bearbeitet: ist er bei jemand anderem in Arbeit, ist er nur anzusehen — nichts geschrieben. Ein ausgeführter Vorgang ist nicht mehr änderbar. Ein Objekt, das ein anderer offener Vorgang hält, ist im Umfang nicht wählbar. Nichts davon mahnt schon.

casa mahnlauf zurueckholen <id> [--position <wert>] --data '<json>'

• Endpunkt: POST /api/mahnlauf/{id}/ausschluss/aufheben
• Token nötig: ja
• Argumente: <id> (exakte Stelligkeit — zu viele sind ebenfalls ein Bedienfehler)
• Body-Flags: --position → Body-Feld positionsSchluessel
• Body: Pflicht (--data '<json>')

casa mahnlauf ausfuehren

Führt einen vorbereiteten Mahnlauf-Vorgang aus: <vorgangId>. Erzeugt je Schreiben einen Eintrag und gibt die unauffälligen Schreiben frei; markierte Schreiben sind danach einzeln freizugeben (mahnlauf freigeben), der Versand ist ein eigener Schritt (mahnlauf versand). Ein zweiter Aufruf liefert das Erst-Ergebnis ("erstAusfuehrung": false). Wirkt nach außen: verlangt eine frische Anmeldung (casa auth login --frisch, sonst 403 step_up_required und nichts geschrieben) und das Ausführungsrecht; ein Agent darf nicht (403, nichts geschrieben). Eine Selbstfreigabe wird je nach Mandantenregel abgelehnt (403).

casa mahnlauf ausfuehren <id>

• Endpunkt: POST /api/mahnlauf/{id}/ausfuehren
• Token nötig: ja
• Argumente: <id> (exakte Stelligkeit — zu viele sind ebenfalls ein Bedienfehler)
• Body: keiner

casa mahnlauf versand

Versendet die Schreiben eines AUSGEFÜHRTEN Vorgangs: <vorgangId> --versandweg mail\|druck (Pflicht, sonst Bedienfehler ohne Netzaufruf); optional --data '{"mahnschreibenIds":["<uuid>"]}' setzt den Versand nur für diese Schreiben fort. Antwort: Zähler (versandt, fehlgeschlagen, uebersprungen) und je Schreiben der Ausgang. Der Versand hat eine eigene frische Anmeldung (ein zweiter Versand desselben Laufs oder Schreibens ist ausgeschlossen: 409, die Anmeldung wird nicht verbraucht), und er geht nur, wenn der Vorgang ausgeführt ist und mindestens ein Schreiben "download_bereit" ist. Wirkt nach außen: verlangt eine frische Anmeldung (casa auth login --frisch, sonst 403 step_up_required und nichts geschrieben) und das Ausführungsrecht; ein Agent darf nicht (403, nichts geschrieben). Eine Selbstfreigabe wird je nach Mandantenregel abgelehnt (403).

casa mahnlauf versand <id> [--versandweg <wert>] --data '<json>'

• Endpunkt: POST /api/mahnlauf/{id}/versand
• Token nötig: ja
• Argumente: <id> (exakte Stelligkeit — zu viele sind ebenfalls ein Bedienfehler)
• Body-Flags: --versandweg → Body-Feld versandweg
• Body: Pflicht (--data '<json>')

casa mahnlauf freigeben

Entscheidet über EIN Schreiben einzeln: <vorgangId> <schreibenId> --entscheidung freigeben\|zurueckweisen (Pflicht). Beim Zurückweisen ist --grund <Code> Pflicht (falscher-betrag, falscher-kreditor, falsche-kontierung, kein-beleg, doppelt, nicht-plausibel, sonstiges), optional --notiz "<Text>" (höchstens 500 Zeichen); bei freigeben ist kein Grund erlaubt. Nach freigeben folgt der Versand genau dieses Schreibens (Versandweg mail, eigene frische Anmeldung); eine rote Ampel ist nicht freigebbar. Wirkt nach außen: verlangt eine frische Anmeldung (casa auth login --frisch, sonst 403 step_up_required und nichts geschrieben) und das Ausführungsrecht; ein Agent darf nicht (403, nichts geschrieben). Eine Selbstfreigabe wird je nach Mandantenregel abgelehnt (403).

casa mahnlauf freigeben <id> <schreibenId> [--entscheidung <wert>] [--grund <wert>] [--notiz <wert>] --data '<json>'

• Endpunkt: POST /api/mahnlauf/{id}/schreiben/{schreibenId}/freigabe
• Token nötig: ja
• Argumente: <id>, <schreibenId> (exakte Stelligkeit — zu viele sind ebenfalls ein Bedienfehler)
• Body-Flags: --entscheidung → Body-Feld entscheidung, --grund → Body-Feld grundCode, --notiz → Body-Feld grundNotiz
• Body: Pflicht (--data '<json>')

casa mahnlauf zustellung

Dokumentiert die von Hand erfolgte Zustellung EINES Schreibens: <vorgangId> <schreibenId> --am <JJJJ-MM-TT> --kanal brief\|einschreiben\|persoenliche_uebergabe --bestaetigt (Schalter: "ich bestätige, dass die Zustellung tatsächlich erfolgt ist"; ohne ihn 400). Genau ein Nachweis je Schreiben: eine zweite Dokumentation ⇒ 409 (bereits-dokumentiert). Wirkt nach außen: verlangt eine frische Anmeldung (casa auth login --frisch, sonst 403 step_up_required und nichts geschrieben) und das Ausführungsrecht; ein Agent darf nicht (403, nichts geschrieben). Eine Selbstfreigabe wird je nach Mandantenregel abgelehnt (403).

casa mahnlauf zustellung <id> <schreibenId> [--am <wert>] [--kanal <wert>] [--bestaetigt] --data '<json>'

• Endpunkt: POST /api/mahnlauf/{id}/schreiben/{schreibenId}/zustellung
• Token nötig: ja
• Argumente: <id>, <schreibenId> (exakte Stelligkeit — zu viele sind ebenfalls ein Bedienfehler)
• Body-Flags: --am → Body-Feld zugestelltAm, --kanal → Body-Feld kanal, --bestaetigt → Body-Feld tatsacheBestaetigt
• Body: Pflicht (--data '<json>')

casa mahnlauf erneut

Sendet EIN fehlgeschlagenes Schreiben erneut: <vorgangId> <schreibenId>. Nur für den Status "fehlgeschlagen" (sonst 409); ein zweiter Versand desselben Schreibens ist ausgeschlossen. Schlägt der Weg wieder fehl, steht "ausgang": "fehlgeschlagen" in der Antwort (Exit 0). Wirkt nach außen: verlangt eine frische Anmeldung (casa auth login --frisch, sonst 403 step_up_required und nichts geschrieben) und das Ausführungsrecht; ein Agent darf nicht (403, nichts geschrieben). Eine Selbstfreigabe wird je nach Mandantenregel abgelehnt (403).

casa mahnlauf erneut <id> <schreibenId>

• Endpunkt: POST /api/mahnlauf/{id}/schreiben/{schreibenId}/erneut
• Token nötig: ja
• Argumente: <id>, <schreibenId> (exakte Stelligkeit — zu viele sind ebenfalls ein Bedienfehler)
• Body: keiner

casa mahnlauf schreiben

Lädt die Datei EINES Mahnschreibens nach --out <pfad> (Pflicht, sonst Bedienfehler ohne Netzaufruf): <vorgangId> <schreibenId>; byte-genau, die CLI prüft die sha256; ein vorhandenes Ziel nur mit --ueberschreiben. Im Umschlag steht "geschriebenNach" statt der Base64-Bytes. Der Download wird vermerkt. Keine Außenwirkung, keine frische Anmeldung nötig. Schreiben eines fremden Vorgangs ⇒ 404.

casa mahnlauf schreiben <id> <schreibenId>

• Endpunkt: GET /api/mahnlauf/{id}/schreiben/{schreibenId}/datei
• Token nötig: ja
• Argumente: <id>, <schreibenId> (exakte Stelligkeit — zu viele sind ebenfalls ein Bedienfehler)
• Datei-Ausgabe: --out <pfad> (Pflicht; die Bytes der Antwort-Datei datei werden byte-genau dorthin geschrieben, --ueberschreiben ersetzt ein vorhandenes Ziel)
• Body: keiner

inkasso

casa inkasso list

Listet die Inkasso-Übergaben des Mandanten, neueste zuerst: --objekt <objektId> und --status entwurf\|uebergeben\|zurueckgenommen\|abgeschlossen schränken ein. Cent-Felder sind Integer-STRINGS; Empfänger, Begründung, Grund und Notiz sind Freitext. Nur lesend. Die Übergabe ist ein Datensatz: sie sendet nichts an Dritte und erzeugt kein Partnerformat.

casa inkasso list [--objekt <wert>] [--status <wert>]

• Endpunkt: GET /api/inkasso
• Token nötig: ja
• Query-Flags: --objekt, --status
• Body: keiner

casa inkasso show

Zeigt EINE Inkasso-Übergabe: <id>. Kopf (Weg, Status, Stichtag, Gesamtforderung), die eingefrorene Forderungsaufstellung (je Posten Hauptforderung, Mahnstufe, Mahngebühren, Verzugszinsen bis zum Stichtag, alle Beträge als Integer-STRINGS in Cent, dazu Tageszins und Hinweise) und die Postenliste. Fremde oder unbekannte Übergabe ⇒ dieselbe 404. Nur lesend; die Übergabe sendet nichts an Dritte.

casa inkasso show <id>

• Endpunkt: GET /api/inkasso/{id}
• Token nötig: ja
• Argumente: <id> (exakte Stelligkeit — zu viele sind ebenfalls ein Bedienfehler)
• Body: keiner

casa inkasso anlegen

Legt eine Inkasso-Übergabe als ENTWURF an: --objekt <objektId> --schuldner <personId> [--vertrag <vertragId>] --weg inkasso\|gerichtliches-mahnverfahren\|klage [--empfaenger "<Text>"] --stichtag <JJJJ-MM-TT> und die Posten als --data '{"offenePostenIds":["<uuid>",…]}'. Die Forderungsaufstellung (Hauptforderung, Mahngebühren, Verzugszinsen bis zum Stichtag) wird gebildet, gehasht und eingefroren. Voraussetzung ist Mahnstufe 3 oder anwalt; darunter nur mit --begruendung-mahnstufe "<Text>". Derselbe Posten kann nicht in zwei aktiven Übergaben stehen (409). Die Übergabe ist ein Datensatz: sie sendet nichts an Dritte und erzeugt kein Partnerformat. Mit "inkasso uebergeben" wird sie übergeben.

casa inkasso anlegen [--objekt <wert>] [--schuldner <wert>] [--vertrag <wert>] [--weg <wert>] [--empfaenger <wert>] [--stichtag <wert>] [--begruendung-mahnstufe <wert>] --data '<json>'

• Endpunkt: POST /api/inkasso
• Token nötig: ja
• Body-Flags: --objekt → Body-Feld propertyId, --schuldner → Body-Feld personId, --vertrag → Body-Feld contractId, --weg → Body-Feld weg, --empfaenger → Body-Feld empfaenger, --stichtag → Body-Feld stichtag, --begruendung-mahnstufe → Body-Feld begruendungMahnstufe
• Body: Pflicht (--data '<json>')

casa inkasso uebergeben

Übergibt den Entwurf: <id> --am <JJJJ-MM-TT> (Pflicht). Setzt den Mahnstatus jedes Postens auf "Beim Rechtsanwalt" (anwalt), in derselben Transaktion. Die Übergabe ist ein Datensatz: sie sendet nichts an Dritte und erzeugt kein Partnerformat. Eine zweite Übergabe ⇒ 409.

casa inkasso uebergeben <id> [--am <wert>] --data '<json>'

• Endpunkt: POST /api/inkasso/{id}/uebergabe
• Token nötig: ja
• Argumente: <id> (exakte Stelligkeit — zu viele sind ebenfalls ein Bedienfehler)
• Body-Flags: --am → Body-Feld uebergebenAm
• Body: Pflicht (--data '<json>')

casa inkasso zuruecknehmen

Nimmt die Übergabe zurück: <id> --grund "<Text>" (Pflicht, höchstens 500 Zeichen; ohne Grund wird nichts gesendet). Die Posten werden frei; der Mahnstatus "Beim Rechtsanwalt" wird NICHT zurückgestuft. Die Übergabe ist ein Datensatz: sie sendet nichts an Dritte.

casa inkasso zuruecknehmen <id> [--grund <wert>] --data '<json>'

• Endpunkt: POST /api/inkasso/{id}/zuruecknahme
• Token nötig: ja
• Argumente: <id> (exakte Stelligkeit — zu viele sind ebenfalls ein Bedienfehler)
• Body-Flags: --grund → Body-Feld grund
• Body: Pflicht (--data '<json>')

casa inkasso abschliessen

Schließt die übergebene Übergabe ab: <id> --art bezahlt\|vergleich\|uneinbringlich\|sonstiges (Pflicht) [--notiz "<Text>"]. Die Posten werden frei. Die Übergabe ist ein Datensatz: sie sendet nichts an Dritte.

casa inkasso abschliessen <id> [--art <wert>] [--notiz <wert>] --data '<json>'

• Endpunkt: POST /api/inkasso/{id}/abschluss
• Token nötig: ja
• Argumente: <id> (exakte Stelligkeit — zu viele sind ebenfalls ein Bedienfehler)
• Body-Flags: --art → Body-Feld art, --notiz → Body-Feld notiz
• Body: Pflicht (--data '<json>')

casa inkasso aufstellung

Schreibt die Forderungsaufstellung einer Übergabe als CSV-Datei nach --out <pfad> (Pflicht, sonst Bedienfehler ohne Netzaufruf): <id>; byte-genau, die CLI prüft die sha256; ein vorhandenes Ziel nur mit --ueberschreiben. Die CSV ist Semikolon-getrennt, UTF-8 mit BOM, Dezimalkomma; zweimal geladen ist sie byte-gleich. Im Umschlag steht "geschriebenNach" statt der Base64-Bytes, dazu "aufstellungHash". Reiner Lesezugriff: nichts wird geschrieben oder gesendet — die Übergabe ist ein Datensatz und erzeugt kein Partnerformat.

casa inkasso aufstellung <id>

• Endpunkt: GET /api/inkasso/{id}/forderungsaufstellung
• Token nötig: ja
• Argumente: <id> (exakte Stelligkeit — zu viele sind ebenfalls ein Bedienfehler)
• Datei-Ausgabe: --out <pfad> (Pflicht; die Bytes der Antwort-Datei datei werden byte-genau dorthin geschrieben, --ueberschreiben ersetzt ein vorhandenes Ziel)
• Body: keiner

konto

casa konto list

Listet Konten. --status alle\|aktiv\|archiviert (Default aktiv), --propertyId <uuid> grenzt auf ein Objekt ein.

casa konto list [--status <wert>] [--propertyId <wert>]

• Endpunkt: GET /api/konto
• Token nötig: ja
• Query-Flags: --status, --propertyId
• Body: keiner

casa konto get

Liest EIN Konto samt Kostenkategorie.

casa konto get <id>

• Endpunkt: GET /api/konto/{id}
• Token nötig: ja
• Argumente: <id> (exakte Stelligkeit — zu viele sind ebenfalls ein Bedienfehler)
• Body: keiner

casa konto create

Legt ein Konto an (propertyId, accountNo, name). Braucht --data <json>.

casa konto create --data '<json>'

• Endpunkt: POST /api/konto
• Token nötig: ja
• Body: Pflicht (--data '<json>')

casa konto update

Ändert Konto-Stammfelder (nach Erstbuchung nur den Namen). Braucht --data <json>.

casa konto update <id> --data '<json>'

• Endpunkt: PATCH /api/konto/{id}
• Token nötig: ja
• Argumente: <id> (exakte Stelligkeit — zu viele sind ebenfalls ein Bedienfehler)
• Body: Pflicht (--data '<json>')

casa konto archive

Archiviert ein Konto (archived_at statt Löschen).

casa konto archive <id>

• Endpunkt: POST /api/konto/{id}/archive
• Token nötig: ja
• Argumente: <id> (exakte Stelligkeit — zu viele sind ebenfalls ein Bedienfehler)
• Body: keiner

casa konto umlageschluessel

Ordnet dem Konto einen Umlageschlüssel zu: --schluessel <uuid> (oder --data '{"allocationKeyId":null}' zum Aufheben). Fremdes Objekt/Tenant ⇒ Fehler.

casa konto umlageschluessel <id> [--schluessel <wert>] --data '<json>'

• Endpunkt: POST /api/konto/{id}/umlageschluessel
• Token nötig: ja
• Argumente: <id> (exakte Stelligkeit — zu viele sind ebenfalls ein Bedienfehler)
• Body-Flags: --schluessel → Body-Feld allocationKeyId
• Body: Pflicht (--data '<json>')

bankzugang

casa bankzugang list

Listet die Bankzugänge (BANKSapi) des Mandanten samt Status — ohne Anbieter-Zugangsdaten.

casa bankzugang list

• Endpunkt: GET /api/bankzugang
• Token nötig: ja
• Body: keiner

person

casa person list

Listet Personen. --status alle\|aktiv\|archiviert (Default aktiv).

casa person list [--status <wert>]

• Endpunkt: GET /api/person
• Token nötig: ja
• Query-Flags: --status
• Body: keiner

casa person get

Liest EINE Person.

casa person get <id>

• Endpunkt: GET /api/person/{id}
• Token nötig: ja
• Argumente: <id> (exakte Stelligkeit — zu viele sind ebenfalls ein Bedienfehler)
• Body: keiner

casa person create

Legt eine Person an. Braucht --data <json>.

casa person create --data '<json>'

• Endpunkt: POST /api/person
• Token nötig: ja
• Body: Pflicht (--data '<json>')

casa person update

Ändert Personen-Stammfelder. Braucht --data <json>.

casa person update <id> --data '<json>'

• Endpunkt: PATCH /api/person/{id}
• Token nötig: ja
• Argumente: <id> (exakte Stelligkeit — zu viele sind ebenfalls ein Bedienfehler)
• Body: Pflicht (--data '<json>')

casa person archive

Archiviert eine Person (archived_at statt Löschen). Rollen bleiben unberührt.

casa person archive <id>

• Endpunkt: POST /api/person/{id}/archive
• Token nötig: ja
• Argumente: <id> (exakte Stelligkeit — zu viele sind ebenfalls ein Bedienfehler)
• Body: keiner

kontenrahmen

casa kontenrahmen list

Listet die verfügbaren Musterkontenrahmen.

casa kontenrahmen list

• Endpunkt: GET /api/kontenrahmen
• Token nötig: ja
• Body: keiner

casa kontenrahmen apply

Spielt einen Musterkontenrahmen auf ein Objekt ein (wiederholbar, legt nichts doppelt an). Braucht --data '{"propertyId":"…"}'.

casa kontenrahmen apply <id> --data '<json>'

• Endpunkt: POST /api/kontenrahmen/{id}/apply
• Token nötig: ja
• Argumente: <id> (exakte Stelligkeit — zu viele sind ebenfalls ein Bedienfehler)
• Body: Pflicht (--data '<json>')

rolle

casa rolle list

Listet Rollen. --status alle\|aktiv\|beendet (Default aktiv), --person <uuid>, --asOf <YYYY-MM-DD>.

casa rolle list [--status <wert>] [--person <wert>] [--asOf <wert>]

• Endpunkt: GET /api/rolle
• Token nötig: ja
• Query-Flags: --status, --person, --asOf
• Body: keiner

casa rolle assign

Vergibt einer Person eine Rolle an Objekt ODER Einheit. Braucht --data <json>.

casa rolle assign --data '<json>'

• Endpunkt: POST /api/rolle
• Token nötig: ja
• Body: Pflicht (--data '<json>')

casa rolle end

Beendet eine Rolle zum Stichtag. Braucht --data '{"endDate":"YYYY-MM-DD"}'.

casa rolle end <id> --data '<json>'

• Endpunkt: POST /api/rolle/{id}/end
• Token nötig: ja
• Argumente: <id> (exakte Stelligkeit — zu viele sind ebenfalls ein Bedienfehler)
• Body: Pflicht (--data '<json>')

gebaeude

casa gebaeude list

Listet Gebäude. --status alle\|aktiv\|archiviert (Default aktiv), --objektId <uuid>.

casa gebaeude list [--status <wert>] [--objektId <wert>]

• Endpunkt: GET /api/gebaeude
• Token nötig: ja
• Query-Flags: --status, --objektId
• Body: keiner

casa gebaeude get

Liest EIN Gebäude samt Objektbezug.

casa gebaeude get <id>

• Endpunkt: GET /api/gebaeude/{id}
• Token nötig: ja
• Argumente: <id> (exakte Stelligkeit — zu viele sind ebenfalls ein Bedienfehler)
• Body: keiner

casa gebaeude create

Legt ein Gebäude an einem aktiven Objekt an. Braucht --data <json> mit propertyId.

casa gebaeude create --data '<json>'

• Endpunkt: POST /api/gebaeude
• Token nötig: ja
• Body: Pflicht (--data '<json>')

casa gebaeude update

Ändert die Gebäude-Adresse. Braucht --data <json>. (propertyId ist nicht änderbar.)

casa gebaeude update <id> --data '<json>'

• Endpunkt: PATCH /api/gebaeude/{id}
• Token nötig: ja
• Argumente: <id> (exakte Stelligkeit — zu viele sind ebenfalls ein Bedienfehler)
• Body: Pflicht (--data '<json>')

casa gebaeude archive

Archiviert ein Gebäude (archived_at statt Löschen; kaskadiert auf alle Einheiten des Gebäudes).

casa gebaeude archive <id>

• Endpunkt: POST /api/gebaeude/{id}/archive
• Token nötig: ja
• Argumente: <id> (exakte Stelligkeit — zu viele sind ebenfalls ein Bedienfehler)
• Body: keiner

einheit

casa einheit list

Listet Einheiten. --status alle\|aktiv\|archiviert (Default aktiv), --gebaeudeId/--objektId <uuid>.

casa einheit list [--status <wert>] [--gebaeudeId <wert>] [--objektId <wert>]

• Endpunkt: GET /api/einheit
• Token nötig: ja
• Query-Flags: --status, --gebaeudeId, --objektId
• Body: keiner

casa einheit get

Liest EINE Einheit samt Gebäude- und Objektbezug.

casa einheit get <id>

• Endpunkt: GET /api/einheit/{id}
• Token nötig: ja
• Argumente: <id> (exakte Stelligkeit — zu viele sind ebenfalls ein Bedienfehler)
• Body: keiner

casa einheit wechselzeitraum

Vorabprüfung: passt ein nachträglich zu erfassender früherer Bewohner- oder Eigentümerzeitraum in den Bestand der Einheit? Schreibt nichts. Pflicht: --art bewohner\|eigentuemer --von JJJJ-MM-TT --bis JJJJ-MM-TT; beide Tage sind inklusive. Ergebnis "code": ok \| ueberlappt (mit der betroffenen Zeile, auch wenn das Ende auf den Beginn des bestehenden Zeitraums fällt) \| zeitraum-verdreht \| beginn-unbekannt. Die Lücke zum nächsten bestehenden Zeitraum wird gemeldet, aber nicht verboten. Erfasst wird über die Belegungs- und Eigentumskommandos.

casa einheit wechselzeitraum <id> [--art <wert>] [--von <wert>] [--bis <wert>]

• Endpunkt: GET /api/einheit/{id}/wechselzeitraum
• Token nötig: ja
• Argumente: <id> (exakte Stelligkeit — zu viele sind ebenfalls ein Bedienfehler)
• Query-Flags: --art, --von, --bis
• Body: keiner

casa einheit create

Legt eine Einheit an einem aktiven Gebäude an. Braucht --data <json> mit buildingId, unitNo (je Objekt eindeutig), unitKind, bezeichnung.

casa einheit create --data '<json>'

• Endpunkt: POST /api/einheit
• Token nötig: ja
• Body: Pflicht (--data '<json>')

casa einheit update

Ändert unitNo/unitKind/bezeichnung. Braucht --data <json>. (buildingId ist nicht änderbar.)

casa einheit update <id> --data '<json>'

• Endpunkt: PATCH /api/einheit/{id}
• Token nötig: ja
• Argumente: <id> (exakte Stelligkeit — zu viele sind ebenfalls ein Bedienfehler)
• Body: Pflicht (--data '<json>')

casa einheit archive

Archiviert eine Einheit (archived_at statt Löschen).

casa einheit archive <id>

• Endpunkt: POST /api/einheit/{id}/archive
• Token nötig: ja
• Argumente: <id> (exakte Stelligkeit — zu viele sind ebenfalls ein Bedienfehler)
• Body: keiner

casa einheit attribut list

Liest die Attribut-Historie einer Einheit. --attributeKey <key>, --asOf <YYYY-MM-DD>.

casa einheit attribut list <id> [--attributeKey <wert>] [--asOf <wert>]

• Endpunkt: GET /api/einheit/{id}/attribut
• Token nötig: ja
• Argumente: <id> (exakte Stelligkeit — zu viele sind ebenfalls ein Bedienfehler)
• Query-Flags: --attributeKey, --asOf
• Body: keiner

casa einheit attribut set

Setzt/ändert eine Attribut-Zeitscheibe ab Datum. --ab <YYYY-MM-DD> und --data '{"attributeKey":"flaeche","attributeValue":{…}}'.

casa einheit attribut set <id> [--ab <wert>] --data '<json>'

• Endpunkt: POST /api/einheit/{id}/attribut
• Token nötig: ja
• Argumente: <id> (exakte Stelligkeit — zu viele sind ebenfalls ein Bedienfehler)
• Body-Flags: --ab → Body-Feld validFrom
• Body: Pflicht (--data '<json>')

casa einheit sev-mandat list

Liest die Sondereigentumsverwaltung einer Einheit. OHNE Flags: das zum HEUTIGEN Stichtag wirksame Mandat (mandat: null heisst „am Stichtag keine SEV" — kein Fehler). --stichtag <YYYY-MM-DD> fragt einen anderen Tag, --historie 1 liefert alle Zeitabschnitte.

casa einheit sev-mandat list <id> [--stichtag <wert>] [--historie <wert>]

• Endpunkt: GET /api/einheit/{id}/sev-mandat
• Token nötig: ja
• Argumente: <id> (exakte Stelligkeit — zu viele sind ebenfalls ein Bedienfehler)
• Query-Flags: --stichtag, --historie
• Body: keiner

casa einheit sev-mandat anlegen

Vereinbart die Sondereigentumsverwaltung für einen Eigentümer und diese Einheit. --ab <YYYY-MM-DD> und --data '{"personId":"…","mitMietinkasso":true,"mietgutschriftBasis":"ist","verguetungVermietet":{"art":"prozent","prozentSkaliert":"55000"},"verguetungLeerstand":{"art":"festbetrag","betragCents":"1500"},"hausgeldQuelle":"weg_soll","sonderruecklageRegel":"keine","auszahlungRhythmus":"quartalsweise","sockelbetragCents":"50000","eigentuemerBankkontoId":"…"}'. Geld und Prozent sind ZIFFERN-STRINGS (1 % = "10000"). Nur im PRO-Objekt möglich; die Person muss im ganzen Zeitraum Eigentümerin der Einheit sein.

casa einheit sev-mandat anlegen <id> [--ab <wert>] [--bis <wert>] --data '<json>'

• Endpunkt: POST /api/einheit/{id}/sev-mandat
• Token nötig: ja
• Argumente: <id> (exakte Stelligkeit — zu viele sind ebenfalls ein Bedienfehler)
• Body-Flags: --ab → Body-Feld validFrom, --bis → Body-Feld validTo
• Body: Pflicht (--data '<json>')

casa einheit eigentum anlegen

Erfasst eine Eigentumszeile an der Einheit. Pflicht: --person <personId>, --anteil <Zehntausendstel als Integer-String, > 0, z. B. 5000 = 50 %>, --von <YYYY-MM-DD>. Optional --bis <YYYY-MM-DD> (erster Tag OHNE Eigentum; ohne: unbefristet). Zustellanschrift, Vollmacht, Anschreiben-Empfänger und Umsatzsteuer-Option über --data '{"zustellanweisung":{"empfaengerName":"…","adresse":"…"},"bevollmaechtigung":{"personId":"…","fenster":{"von":"2026-01-01"}},"anschreibenEmpfaenger":true,"ustOption":false}'. Ein Eigentümerwechsel im Jahr ist KEIN anlegen+beenden, sondern casa einheit eigentuemerwechsel. Nur in WEG- und PRO-Objekten.

casa einheit eigentum anlegen <id> [--person <wert>] [--anteil <wert>] [--von <wert>] [--bis <wert>] --data '<json>'

• Endpunkt: POST /api/einheit/{id}/eigentum
• Token nötig: ja
• Argumente: <id> (exakte Stelligkeit — zu viele sind ebenfalls ein Bedienfehler)
• Body-Flags: --person → Body-Feld personId, --anteil → Body-Feld anteil, --von → Body-Feld von, --bis → Body-Feld bisExklusiv
• Body: Pflicht (--data '<json>')

casa einheit eigentuemerwechsel

Erfasst einen Eigentümerwechsel als EINEN Vorgang: die abgehenden Eigentumszeilen enden am Stichtag, die neuen beginnen an ihm. Der Stichtag ist die Eintragung im Grundbuch, Abteilung I — NICHT der Notartermin: --grundbuch <YYYY-MM-DD>. Optional --zustimmung <YYYY-MM-DD> (Verwalterzustimmung). Abgehende und neue Zeilen über --data '{"abgehend":[{"ownershipId":"…"}],"neu":[{"personId":"…","anteil":"10000"}]}' (Anteile in Zehntausendsteln als Integer-String; je neue Zeile optional zustellanweisung, bevollmaechtigung, anschreibenEmpfaenger, ustOption). Laufende SEV-Mandate abgehender Eigentümer werden NICHT beendet, sondern in "sevMandateOffen" genannt. Bisherige Wechsel: casa einheit eigentuemerwechsel list <einheitId>.

casa einheit eigentuemerwechsel <id> [--grundbuch <wert>] [--zustimmung <wert>] --data '<json>'

• Endpunkt: POST /api/einheit/{id}/eigentuemerwechsel
• Token nötig: ja
• Argumente: <id> (exakte Stelligkeit — zu viele sind ebenfalls ein Bedienfehler)
• Body-Flags: --grundbuch → Body-Feld grundbuchEintragungAm, --zustimmung → Body-Feld verwalterzustimmungAm
• Body: Pflicht (--data '<json>')

casa einheit eigentuemerwechsel list

Listet die Eigentümerwechsel einer Einheit, aufsteigend nach Grundbuch-Stichtag, mit Verwalterzustimmung sowie den abgehenden und neuen Eigentumszeilen (ownershipIds). Eine Einheit ohne Wechsel ist eine leere Liste, kein Fehler.

casa einheit eigentuemerwechsel list <id>

• Endpunkt: GET /api/einheit/{id}/eigentuemerwechsel
• Token nötig: ja
• Argumente: <id> (exakte Stelligkeit — zu viele sind ebenfalls ein Bedienfehler)
• Body: keiner

sev-mandat

casa sev-mandat beenden

Beendet einen SEV-Zeitabschnitt. --data '{"endeExklusiv":"2025-07-01"}' — endeExklusiv ist der erste Tag OHNE Sondereigentumsverwaltung: „zum 30.06. beendet" ⇒ 2025-07-01. Beenden KÜRZT nur — die Historie bleibt stehen, damit eine abgerechnete Periode erklärbar bleibt; dasselbe Ende ein zweites Mal ist ein Erfolg ohne Änderung.

casa sev-mandat beenden <id> --data '<json>'

• Endpunkt: POST /api/sev-mandat/{id}/beenden
• Token nötig: ja
• Argumente: <id> (exakte Stelligkeit — zu viele sind ebenfalls ein Bedienfehler)
• Body: Pflicht (--data '<json>')

casa sev-mandat eigentuemerabrechnung

Liest die Jahresabrechnung der Sondereigentumsverwaltung für den Eigentümer: Einnahmen, Ausgaben und Auszahlungen je Buchungsart, Mieteinnahmen (Soll, Ist, Ausfall, Ertrag je m²), Kosten der Wohnung und die Entwicklung des Geldbestands mit Probe gegen das Verrechnungskonto, dazu der Empfänger mit Anrede und Anschrift. --von <YYYY-MM-DD> und --bis <YYYY-MM-DD> sind Pflicht (beide inklusiv); --mitAuszahlung false blendet die Auszahlungs-Positionen aus (Summe und Geldbestand bleiben). Ein Mandat ohne Mietinkasso hat keine Abrechnung; ein Eigentümer ohne Anschrift ist ein Fehler, kein leeres Adressfeld.

casa sev-mandat eigentuemerabrechnung <id> [--von <wert>] [--bis <wert>] [--mitAuszahlung <wert>]

• Endpunkt: GET /api/sev-mandat/{id}/eigentuemerabrechnung
• Token nötig: ja
• Argumente: <id> (exakte Stelligkeit — zu viele sind ebenfalls ein Bedienfehler)
• Query-Flags: --von, --bis, --mitAuszahlung
• Body: keiner

eigentum

casa eigentum beenden

Beendet eine Eigentumszeile (die Id ist die ownershipId aus casa objekt eigentum list). Pflicht: --ende <YYYY-MM-DD> — der erste Tag OHNE Eigentum: "zum 30.06. beendet" ⇒ 2025-07-01. Beenden KÜRZT nur das Zeitfenster, die Historie bleibt; dasselbe Ende ein zweites Mal ist ein Erfolg ohne Änderung ("beendet": false). Es gibt kein Löschen. Für einen Eigentümerwechsel casa einheit eigentuemerwechsel nehmen.

casa eigentum beenden <id> [--ende <wert>] --data '<json>'

• Endpunkt: POST /api/eigentum/{id}/beenden
• Token nötig: ja
• Argumente: <id> (exakte Stelligkeit — zu viele sind ebenfalls ein Bedienfehler)
• Body-Flags: --ende → Body-Feld endeExklusiv
• Body: Pflicht (--data '<json>')

versammlung

casa versammlung get

Liest EINE Versammlung: Art, Status, Termine, Einladungsfrist-Begründung, Stimmprinzip und Beschlussfähigkeit (beim Umlaufbeschluss nicht ausgewiesen; sie wird nie berechnet, sondern wie gespeichert gezeigt), das Ende der Anfechtungsfrist, sobald verkündet wurde, sowie Tagesordnung (tops), Teilnehmer (teilnehmer), summeStimmgewicht und anzahlTeilnehmer.

casa versammlung get <id>

• Endpunkt: GET /api/versammlung/{id}
• Token nötig: ja
• Argumente: <id> (exakte Stelligkeit — zu viele sind ebenfalls ein Bedienfehler)
• Body: keiner

casa versammlung aendern

Ändert eine Versammlung: --datum, --einladung, --begruendung, --stimmprinzip, --status durchgefuehrt \| abgesagt (nur entwurf → durchgefuehrt und entwurf\|durchgefuehrt → abgesagt; „abgeschlossen“ setzt allein das Generieren der Beschlüsse). art und Objekt sind nicht änderbar. Einladungsfrist unter 3 Wochen: Warnung (Feld hinweise), Begründung Pflicht, keine Sperre. Sind die Beschlüsse generiert, ist die Versammlung unveränderlich (Konflikt).

casa versammlung aendern <id> [--datum <wert>] [--einladung <wert>] [--begruendung <wert>] [--stimmprinzip <wert>] [--status <wert>] --data '<json>'

• Endpunkt: PATCH /api/versammlung/{id}
• Token nötig: ja
• Argumente: <id> (exakte Stelligkeit — zu viele sind ebenfalls ein Bedienfehler)
• Body-Flags: --datum → Body-Feld versammlungsdatum, --einladung → Body-Feld einladungsdatum, --begruendung → Body-Feld einladungsfristBegruendung, --stimmprinzip → Body-Feld stimmprinzip, --status → Body-Feld status
• Body: Pflicht (--data '<json>')

casa versammlung top

Erfasst einen Tagesordnungspunkt: --bezeichnung <text> (Pflicht), --art beschluss (Default) \| geschaeftsordnung \| notiz, --text <beschlusstext>; weitere Felder per --data (kategorie). Die laufende TOP-Nummer vergibt der Server als nächste freie je Versammlung. Beim Umlaufbeschluss genau ein TOP. Ist die Versammlung abgeschlossen (Beschlüsse generiert), gibt es einen Konflikt.

casa versammlung top <id> [--bezeichnung <wert>] [--art <wert>] [--text <wert>] --data '<json>'

• Endpunkt: POST /api/versammlung/{id}/tops
• Token nötig: ja
• Argumente: <id> (exakte Stelligkeit — zu viele sind ebenfalls ein Bedienfehler)
• Body-Flags: --bezeichnung → Body-Feld bezeichnung, --art → Body-Feld topArt, --text → Body-Feld beschlusstext
• Body: Pflicht (--data '<json>')

casa versammlung top-aendern

Ändert Text und Art eines Tagesordnungspunkts: --bezeichnung, --art beschluss \| geschaeftsordnung \| notiz, --text <beschlusstext>; weitere Felder per --data (kategorie). Die laufende Nummer (Reihenfolge) ist nicht änderbar. Die Art eines TOP mit Ergebnis oder Beschluss bleibt beschluss.

casa versammlung top-aendern <id> <topId> [--bezeichnung <wert>] [--art <wert>] [--text <wert>] --data '<json>'

• Endpunkt: PATCH /api/versammlung/{id}/tops/{topId}
• Token nötig: ja
• Argumente: <id>, <topId> (exakte Stelligkeit — zu viele sind ebenfalls ein Bedienfehler)
• Body-Flags: --bezeichnung → Body-Feld bezeichnung, --art → Body-Feld topArt, --text → Body-Feld beschlusstext
• Body: Pflicht (--data '<json>')

casa versammlung teilnehmer

Setzt einen Teilnehmer mit Stimmrecht (Upsert je Person: erneutes Setzen überschreibt; ein Entfernen gibt es nicht, wer nicht erschienen ist, wird nicht erfasst): --person <personId> und --anwesenheit praesent \| online \| vertreten sind Pflicht, --gewicht <ganze Zahl> das Stimmgewicht (Stimmprinzip koepfe: nur 1 und Default; mea: Zehntausendstel, Pflicht; objekt: Anzahl der Einheiten, Pflicht), --vertreten-durch <text>. Ob die Person Eigentümer des Objekts ist, prüft casa.ai nicht — Gäste, Vertreter und Verwalter sind Teilnehmer. Die Person muss zum Mandanten gehören. Beim Umlaufbeschluss gibt es keine Teilnehmer. Die Beschlussfähigkeit wird nicht berechnet (casa versammlung aendern --data).

casa versammlung teilnehmer <id> [--person <wert>] [--anwesenheit <wert>] [--gewicht <wert>] [--vertreten-durch <wert>] --data '<json>'

• Endpunkt: POST /api/versammlung/{id}/teilnehmer
• Token nötig: ja
• Argumente: <id> (exakte Stelligkeit — zu viele sind ebenfalls ein Bedienfehler)
• Body-Flags: --person → Body-Feld personId, --anwesenheit → Body-Feld anwesenheit, --gewicht → Body-Feld stimmgewicht, --vertreten-durch → Body-Feld vertretenDurch
• Body: Pflicht (--data '<json>')

casa versammlung ergebnis

Erfasst das Abstimmungsergebnis EINES Beschluss-TOP: --ergebnis angenommen \| abgelehnt (Pflicht, die Feststellung; sie wird nie aus den Zahlen abgeleitet), --ja/--nein/--enthaltung (Köpfe) und --anteile-ja/--anteile-nein/--anteile-enthaltung (Zehntausendstel), je eine ganze Zahl >= 0; nicht genannte Zahlen werden leer gespeichert. Erneutes Setzen überschreibt, solange die Versammlung nicht abgeschlossen ist. Geschäftsordnungs- und Notiz-TOPs haben keine Abstimmung (top-ohne-abstimmung). Ein offensichtlicher Widerspruch (angenommen bei mehr Nein- als Ja-Stimmen) steht als Hinweis ergebnis-widerspricht-zahlen in der Antwort, nie als Fehler.

casa versammlung ergebnis <id> <topId> [--ergebnis <wert>] [--ja <wert>] [--nein <wert>] [--enthaltung <wert>] [--anteile-ja <wert>] [--anteile-nein <wert>] [--anteile-enthaltung <wert>] --data '<json>'

• Endpunkt: POST /api/versammlung/{id}/tops/{topId}/ergebnis
• Token nötig: ja
• Argumente: <id>, <topId> (exakte Stelligkeit — zu viele sind ebenfalls ein Bedienfehler)
• Body-Flags: --ergebnis → Body-Feld ergebnis, --ja → Body-Feld stimmenJa, --nein → Body-Feld stimmenNein, --enthaltung → Body-Feld stimmenEnthaltung, --anteile-ja → Body-Feld anteileJa, --anteile-nein → Body-Feld anteileNein, --anteile-enthaltung → Body-Feld anteileEnthaltung
• Body: Pflicht (--data '<json>')

casa versammlung verkuenden

Verkündet die Versammlung: --am <JJJJ-MM-TT> (Pflicht, nicht vor dem Versammlungsdatum, nicht in der Zukunft). Setzt das Verkündungsdatum EINMAL (zweites Verkünden ⇒ bereits-verkuendet). Voraussetzung: Status durchgefuehrt, mindestens ein Beschluss-TOP, jeder Beschluss-TOP hat ein Ergebnis. Die Antwort zeigt anfechtungsfristEnde (ein Monat ab Verkündung, § 45 WEG), das rechnerische Ende und den Hinweis, dass Feiertage nicht berücksichtigt sind.

casa versammlung verkuenden <id> [--am <wert>] --data '<json>'

• Endpunkt: POST /api/versammlung/{id}/verkuendung
• Token nötig: ja
• Argumente: <id> (exakte Stelligkeit — zu viele sind ebenfalls ein Bedienfehler)
• Body-Flags: --am → Body-Feld verkuendetAm
• Body: Pflicht (--data '<json>')

casa versammlung beschluesse-generieren

Übernimmt die verkündeten Beschlüsse der Versammlung in die Beschluss-Sammlung des Objekts (laufende Nummer = größte des Objekts + 1, fortlaufend; TOP-Reihenfolge). Voraussetzung: die Versammlung ist verkündet (versammlung verkuenden), hat mindestens einen Beschluss-TOP und jeder Beschluss-TOP hat ein Ergebnis. Genau EINMAL: danach ist die Versammlung abgeschlossen und unveränderlich, eine zweite Übernahme ⇒ bereits-generiert. Alles oder nichts. Geschäftsordnungs- und Notiz-TOPs werden nicht übernommen; sie stehen als übersprungen in der Antwort. Body: --data '{}'.

casa versammlung beschluesse-generieren <id> --data '<json>'

• Endpunkt: POST /api/versammlung/{id}/beschluesse
• Token nötig: ja
• Argumente: <id> (exakte Stelligkeit — zu viele sind ebenfalls ein Bedienfehler)
• Body: Pflicht (--data '<json>')

casa versammlung umlauf eroeffnen

Eröffnet den Umlaufbeschluss einer Versammlung der Art umlauf (Status entwurf, genau ein Beschluss-TOP): --frist <JJJJ-MM-TT> (Pflicht, Ende der Antwortfrist), --mehrheitsregel allstimmig (Default) \| mehrheit_abgegebene, --absenkung-beschluss <beschlussId> (Pflicht bei mehrheit_abgegebene); Stimmgewichte je Person per --data (stimmgewichte: [{personId, stimmgewicht}], Pflicht bei Stimmprinzip mea und objekt). Legt je Eigentümer-Person eine Rücklaufzeile an. Allstimmigkeit ist der Default (alle Eigentümer in Textform, § 23 Abs. 3 S. 1 WEG); die abgesenkte Mehrheit (--mehrheitsregel mehrheit_abgegebene) braucht einen vorher gefassten Beschluss (--absenkung-beschluss), und das System prüft nicht, ob er sich auf diesen Gegenstand bezieht. Die Frist ist keine Ausschlussfrist: Antworten bis zur Feststellung zählen. Ohne Verkündung gibt es keinen Beschluss in der Sammlung; ein nicht zustande gekommener Umlauf geht als „abgelehnt“ in die Sammlung.

casa versammlung umlauf eroeffnen <id> [--frist <wert>] [--mehrheitsregel <wert>] [--absenkung-beschluss <wert>] --data '<json>'

• Endpunkt: POST /api/versammlung/{id}/umlauf
• Token nötig: ja
• Argumente: <id> (exakte Stelligkeit — zu viele sind ebenfalls ein Bedienfehler)
• Body-Flags: --frist → Body-Feld fristEnde, --mehrheitsregel → Body-Feld mehrheitsregel, --absenkung-beschluss → Body-Feld absenkungBeschlussId
• Body: Pflicht (--data '<json>')

casa versammlung umlauf ruecklauf

Erfasst die Antwort EINER Person: --person <personId> (Eigentümer auf der Rücklaufliste), --antwort ja \| nein \| enthaltung, --am <JJJJ-MM-TT> (Eingangsdatum, nicht vor der Eröffnung, nicht in der Zukunft), --kanal portal \| email \| post \| sonstiges (alle Pflicht), --textform (Schalter: die Textform ist bestätigt; eine Zustimmung gilt nur in Textform), --notiz <text>. Eine spätere Antwort überschreibt die frühere, solange nicht festgestellt ist. Antworten nach dem Fristende zählen (Hinweis nach-fristablauf); die Antwort zeigt den Zählstand. Die Frist ist keine Ausschlussfrist: Antworten bis zur Feststellung zählen.

casa versammlung umlauf ruecklauf <id> [--person <wert>] [--antwort <wert>] [--am <wert>] [--kanal <wert>] [--textform] [--notiz <wert>] --data '<json>'

• Endpunkt: POST /api/versammlung/{id}/umlauf/ruecklauf
• Token nötig: ja
• Argumente: <id> (exakte Stelligkeit — zu viele sind ebenfalls ein Bedienfehler)
• Body-Flags: --person → Body-Feld personId, --antwort → Body-Feld antwort, --am → Body-Feld eingegangenAm, --kanal → Body-Feld eingangskanal, --textform → Body-Feld textformBestaetigt, --notiz → Body-Feld notiz
• Body: Pflicht (--data '<json>')

casa versammlung umlauf stand

Liest den Stand des Umlaufs: Vorgang (Mehrheitsregel, Frist, Feststellung, Mitteilung), Rücklaufliste mit Namen und Stimmgewichten (Integer-Strings), Zählung, fristAbgelaufen und feststellbar (wahr: casa versammlung umlauf feststellen gelingt jetzt). Bis zur Feststellung zählt der Server live mit dem heutigen Tag, danach gilt die eingefrorene Zählung. Allstimmigkeit ist der Default; die abgesenkte Mehrheit rechnet über die abgegebenen Stimmen.

casa versammlung umlauf stand <id>

• Endpunkt: GET /api/versammlung/{id}/umlauf
• Token nötig: ja
• Argumente: <id> (exakte Stelligkeit — zu viele sind ebenfalls ein Bedienfehler)
• Body: keiner

casa versammlung umlauf feststellen

Stellt das Ergebnis des Umlaufs fest (einmalig): friert die Zählung ein und schreibt das Ergebnis in den Beschluss-TOP. Möglich, sobald alle geantwortet haben (Allstimmigkeit: auch bei einem Nein) oder das Fristende vorbei ist (feststellbar im Stand); sonst Konflikt, nichts geschrieben. Ein zweiter Aufruf ⇒ Konflikt umlauf-festgestellt. Kein Body nötig. Ein nicht zustande gekommener Umlauf geht als „abgelehnt“ in die Sammlung.

casa versammlung umlauf feststellen <id> --data '<json>'

• Endpunkt: POST /api/versammlung/{id}/umlauf/feststellung
• Token nötig: ja
• Argumente: <id> (exakte Stelligkeit — zu viele sind ebenfalls ein Bedienfehler)
• Body: Pflicht (--data '<json>')

casa versammlung umlauf verkuenden

Verkündet den festgestellten Umlauf (einmalig): --am <JJJJ-MM-TT> (Verkündungsdatum, nicht vor dem Versammlungsdatum, nicht in der Zukunft) und --form textform \| brief (Form der Mitteilung an die Eigentümer) sind Pflicht. Die Antwort zeigt anfechtungsfristEnde (ein Monat ab Verkündung, § 45 WEG). Auch ein nicht zustande gekommener Umlauf wird verkündet; danach übernimmt casa versammlung beschluesse-generieren das Ergebnis in die Sammlung; ohne Verkündung gibt es keinen Beschluss in der Sammlung.

casa versammlung umlauf verkuenden <id> [--am <wert>] [--form <wert>] --data '<json>'

• Endpunkt: POST /api/versammlung/{id}/umlauf/verkuendung
• Token nötig: ja
• Argumente: <id> (exakte Stelligkeit — zu viele sind ebenfalls ein Bedienfehler)
• Body-Flags: --am → Body-Feld verkuendetAm, --form → Body-Feld mitteilungForm
• Body: Pflicht (--data '<json>')

abschluss

casa abschluss freeze

Fragt, ob an einer Abrechnung noch geschrieben werden darf. --vorhaben storno\|neuberechnung ist Pflicht. Ein bestandskräftiger Lauf + neuberechnung endet NICHT mit 0 und nennt den Korrekturweg — ein stilles „nichts passiert" sähe für den Bediener wie Erfolg aus.

casa abschluss freeze <id> [--vorhaben <wert>]

• Endpunkt: GET /api/abschluss/{id}/freeze
• Token nötig: ja
• Argumente: <id> (exakte Stelligkeit — zu viele sind ebenfalls ein Bedienfehler)
• Query-Flags: --vorhaben
• Body: keiner

casa abschluss storno

Storniert EINEN Abschluss-Lauf. --grund und --stichtag sind Pflicht: ein Storno ohne Begründung ist im Audit wertlos, und der Tag darf nicht aus der Uhr des Servers kommen (BP §8). Ein zweites Storno desselben Laufs wird abgewiesen.

casa abschluss storno <id> [--grund <wert>] [--stichtag <wert>] --data '<json>'

• Endpunkt: POST /api/abschluss/{id}/storno
• Token nötig: ja
• Argumente: <id> (exakte Stelligkeit — zu viele sind ebenfalls ein Bedienfehler)
• Body-Flags: --grund → Body-Feld grund, --stichtag → Body-Feld stichtag
• Body: Pflicht (--data '<json>')

datev

casa datev buchungsstapel

Erzeugt den DATEV-Buchungsstapel (EXTF 700) für ein oder mehrere Objekte und ein Kalenderjahr und schreibt die Datei nach --out <pfad> (Windows-1252, byte-genau; vorhandenes Ziel nur mit --ueberschreiben). Der Lauf steht danach in der Export-Historie. Pflicht: --objekte <uuid[,uuid…]> ("alle" ist eine Wahl, kein Vorgabewert), --jahr JJJJ (Kalenderjahr; Zeitraum 01.01. bis 31.12., mit abweichendem --wirtschaftsjahr-beginn nur der Teil des Jahres, der in diesem Wirtschaftsjahr liegt), --beraternummer (1-7 Ziffern), --mandantennummer (1-5 Ziffern), --sachkontenlaenge 4-8, --kontenrahmen skr03\|skr04, --festschreibung 0\|1, --out. Optional: --wirtschaftsjahr-beginn JJJJ-MM-TT (Vorgabe: 01.01. des Jahres). --festschreibung ist das Festschreibekennzeichen im Kopfsatz (GoBD-Angabe an DATEV): 1 = die Daten gelten bei DATEV als festgeschrieben, 0 = nicht; es gibt keinen Vorgabewert. Der Export löst KEINE Festschreibung in casa.ai aus. Das Ergebnis nennt Anzahl (buchungszeilen, buchungssaetze), summeCents, dateiname, sha256 und laufId; ist der Zeitraum nicht durch festgeschriebene Perioden gedeckt, steht der Hinweis dazu in "hinweise" (Hinweis, kein Abweis; die Datei wird trotzdem geschrieben). Abweichendes Wirtschaftsjahr: zwei Stapel, also zwei Läufe für zwei Kalenderjahre (--jahr 2024 ⇒ 01.07.–31.12.2024, --jahr 2025 ⇒ 01.01.–30.06.2025; berührt das Wirtschaftsjahr das Jahr nicht ⇒ 400), z. B. casa datev buchungsstapel --objekte <uuid> --jahr 2024 --wirtschaftsjahr-beginn 2024-07-01 --out a.csv … und danach --jahr 2025 --wirtschaftsjahr-beginn 2024-07-01 --out b.csv …. Leerer Umfang, fehlende Kontenzuordnung, falsche Sachkontenlänge ⇒ 409 mit Klartext, keine Datei; fremdes oder nicht zuständiges Objekt ⇒ 404. Wiederholungssicher mit --idempotency-key.

casa datev buchungsstapel [--objekte <wert>] [--jahr <wert>] [--beraternummer <wert>] [--mandantennummer <wert>] [--sachkontenlaenge <wert>] [--kontenrahmen <wert>] [--festschreibung <wert>] [--wirtschaftsjahr-beginn <wert>] --data '<json>'

• Endpunkt: POST /api/datev/buchungsstapel
• Token nötig: ja
• Datei-Ausgabe: --out <pfad> (Pflicht; die Bytes der Antwort-Datei datei werden byte-genau dorthin geschrieben, --ueberschreiben ersetzt ein vorhandenes Ziel)
• Body-Flags: --objekte → Body-Feld objekte, --jahr → Body-Feld jahr, --beraternummer → Body-Feld beraternummer, --mandantennummer → Body-Feld mandantennummer, --sachkontenlaenge → Body-Feld sachkontenlaenge, --kontenrahmen → Body-Feld kontenrahmen, --festschreibung → Body-Feld festschreibung, --wirtschaftsjahr-beginn → Body-Feld wirtschaftsjahrBeginn
• Body: Pflicht (--data '<json>')

casa datev historie

Listet die früheren DATEV-Buchungsstapel-Läufe, jüngster zuerst: laufId, Zeitraum (zeitraumVon/zeitraumBis), objekte, dateiname, sha256, buchungszeilen, summeCents, erzeugtAm und erzeugende Person; nie Buchungstexte und keine Datei-Bytes. Optional --objekt <uuid> (mehrere kommagetrennt) grenzt auf Läufe ein, die eines dieser Objekte berühren, --limit <1..200> bestimmt die Seitengröße, --weiter <cursor> holt die nächste Seite (der Wert "weiter" der vorigen Antwort; null = Historie zu Ende). Gezeigt werden Läufe über die Objekte, für die Sie zuständig sind; ein Lauf über mehrere Objekte steht (nur als Kennzahlen) in der Liste jedes seiner Objekte. Die Historie hält nur die Stapel-Datei: ein Belegpaket (ZIP) und die DebKred-Datei sind nicht darin. Die Datei eines Laufs holt "datev herunterladen <laufId> --out <pfad>". Lesen erzeugt keinen Lauf und keinen Eintrag.

casa datev historie [--objekt <wert>] [--limit <wert>] [--weiter <wert>]

• Endpunkt: GET /api/datev/historie
• Token nötig: ja
• Query-Flags: --objekt, --limit, --weiter
• Body: keiner

casa datev herunterladen

Lädt die Stapel-Datei eines früheren Laufs (Positional <laufId> aus "datev historie") erneut nach --out <pfad>: byte-gleich zum ursprünglichen Export (gleiche sha256), ohne neuen Buchungslauf, ohne neuen Kommando-Log-Eintrag und ohne neue Historien-Zeile; ein vorhandenes Ziel nur mit --ueberschreiben. Nur die Stapel-Datei liegt in der Historie: ein Belegpaket (ZIP) und die DebKred-Datei sind nicht darin und nicht erneut holbar. Unbekannte, fremde oder nicht vollständig zuständige laufId (ein Lauf über Objekte, für die Sie nicht alle zuständig sind) ⇒ 404 (not_found), keine Datei. Passen die abgelegten Bytes nicht mehr zu ihrer sha256, gibt es einen Serverfehler und keine Datei.

casa datev herunterladen <laufId>

• Endpunkt: GET /api/datev/historie/{laufId}/datei
• Token nötig: ja
• Argumente: <laufId> (exakte Stelligkeit — zu viele sind ebenfalls ein Bedienfehler)
• Datei-Ausgabe: --out <pfad> (Pflicht; die Bytes der Antwort-Datei datei werden byte-genau dorthin geschrieben, --ueberschreiben ersetzt ein vorhandenes Ziel)
• Body: keiner

casa datev belegpaket

Erzeugt den DATEV-Buchungsstapel MIT Beleglinks und das zugehörige Belegpaket (ZIP mit document.xml und den unveränderten Original-Belegen) in einem Lauf und schreibt zwei Dateien: den Stapel nach --out <pfad> (Windows-1252) und das ZIP nach --belegpaket-out <pfad>; beide byte-genau, vorhandene Ziele nur mit --ueberschreiben. Dieselben Pflicht-Flags wie "datev buchungsstapel" (--objekte, --jahr, --beraternummer, --mandantennummer, --sachkontenlaenge, --kontenrahmen, --festschreibung; optional --wirtschaftsjahr-beginn) plus beide Ziele. --belegpaket-out ist Pflicht, weil die CLI vor dem Aufruf nicht wissen kann, ob Belege existieren; fehlt es, gibt es einen Bedienfehler und keinen Netzaufruf. Hat keine Buchung einen übertragbaren Beleg, gibt es kein ZIP: "belegpaket" ist dann null, --belegpaket-out wird nicht geschrieben und "hinweis" nennt den Grund; der Stapel wird trotzdem geschrieben. "ohneBeleg" listet die Buchungszeilen ohne Beleg im Paket (zeilenNr und grund, nie Buchungstext oder Namen); eine Buchung mit Hash-Abweichung des Originals gilt als nicht übertragbar (original_beschaedigt). Der Lauf ist derselbe wie bei "datev buchungsstapel" (eine Historien-Zeile): in der Export-Historie liegt danach nur die Stapel-Datei mit den Beleglinks; das ZIP wird NICHT abgelegt und ist nur in dieser Antwort holbar (siehe "hinweise" in "stapel"), also jetzt sichern. Die Festschreibung löst der Export nicht aus (--festschreibung ist nur das Kennzeichen im Kopfsatz). Leerer Umfang, fehlende Kontenzuordnung, falsche Sachkontenlänge ⇒ 409 mit Klartext, keine Datei; fremdes oder nicht zuständiges Objekt ⇒ 404; Belegspeicher nicht erreichbar ⇒ 503, nichts exportiert und keine Historien-Zeile. KEIN Replay: ein zweiter Aufruf mit demselben --idempotency-key liefert das ZIP nicht erneut (es wird nicht abgelegt, und der Zeitstempel im Stapel ist je Aufruf ein anderer), sondern endet mit 409 conflict; die Historie behält genau eine Zeile. Für eine erneute Datei einen neuen Schlüssel verwenden.

casa datev belegpaket [--objekte <wert>] [--jahr <wert>] [--beraternummer <wert>] [--mandantennummer <wert>] [--sachkontenlaenge <wert>] [--kontenrahmen <wert>] [--festschreibung <wert>] [--wirtschaftsjahr-beginn <wert>] --data '<json>'

• Endpunkt: POST /api/datev/belegpaket
• Token nötig: ja
• Datei-Ausgabe: --out <pfad> (Pflicht; die Bytes der Antwort-Datei stapel.datei werden byte-genau dorthin geschrieben, --ueberschreiben ersetzt ein vorhandenes Ziel); --belegpaket-out <pfad> (Pflicht; Antwort-Datei belegpaket, bei null nicht geschrieben)
• Body-Flags: --objekte → Body-Feld objekte, --jahr → Body-Feld jahr, --beraternummer → Body-Feld beraternummer, --mandantennummer → Body-Feld mandantennummer, --sachkontenlaenge → Body-Feld sachkontenlaenge, --kontenrahmen → Body-Feld kontenrahmen, --festschreibung → Body-Feld festschreibung, --wirtschaftsjahr-beginn → Body-Feld wirtschaftsjahrBeginn
• Body: Pflicht (--data '<json>')

casa datev debkred

Erzeugt die DATEV-Stammdatendatei Debitoren/Kreditoren (EXTF, Personenkonten mit Name, Anschrift und bestätigter IBAN) zu einem Buchungsstapel und schreibt sie nach --out <pfad> (Windows-1252, byte-genau; vorhandenes Ziel nur mit --ueberschreiben). Dieselben Pflicht-Flags wie "datev buchungsstapel" (--objekte, --jahr, --beraternummer, --mandantennummer, --sachkontenlaenge, --kontenrahmen, --festschreibung, --out; optional --wirtschaftsjahr-beginn) plus --umfang buchungsstapel\|alle-aktiven (Pflicht, kein Vorgabewert): "buchungsstapel" = genau die Personenkonten des Stapels desselben Zeitraums, "alle-aktiven" = zusätzlich jedes nicht archivierte Personenkonto der Objekte und alle Kreditoren. Das Ergebnis nennt dateiname, sha256, personenkonten und mitBankverbindung (Zahlen, keine IBAN). ACHTUNG: Die Datei enthält Namen, Anschriften und IBANs. Sie wird NICHT in der Export-Historie abgelegt und ist nicht erneut abrufbar (Hinweis in "hinweise": nicht in der Historie abgelegt, Datei jetzt sichern); der Beleg im Kommando-Log trägt nur sha256 und Zahlen. Leerer Umfang, fehlende Kontenzuordnung, falsche Sachkontenlänge, Personenkonto ohne Geschäftspartner ⇒ 409 mit Klartext (ohne Namen), keine Datei; fremdes oder nicht zuständiges Objekt ⇒ 404. Wiederholungssicher mit --idempotency-key: ein Retry mit gleichem Key, gleichen Flags und unveränderten Stammdaten liefert dieselbe Datei erneut (ohne Ablage); anderer Body oder geänderte Stammdaten unter demselben Key ⇒ 409, keine Datei.

casa datev debkred [--objekte <wert>] [--jahr <wert>] [--beraternummer <wert>] [--mandantennummer <wert>] [--sachkontenlaenge <wert>] [--kontenrahmen <wert>] [--festschreibung <wert>] [--wirtschaftsjahr-beginn <wert>] [--umfang <wert>] --data '<json>'

• Endpunkt: POST /api/datev/debkred
• Token nötig: ja
• Datei-Ausgabe: --out <pfad> (Pflicht; die Bytes der Antwort-Datei datei werden byte-genau dorthin geschrieben, --ueberschreiben ersetzt ein vorhandenes Ziel)
• Body-Flags: --objekte → Body-Feld objekte, --jahr → Body-Feld jahr, --beraternummer → Body-Feld beraternummer, --mandantennummer → Body-Feld mandantennummer, --sachkontenlaenge → Body-Feld sachkontenlaenge, --kontenrahmen → Body-Feld kontenrahmen, --festschreibung → Body-Feld festschreibung, --wirtschaftsjahr-beginn → Body-Feld wirtschaftsjahrBeginn, --umfang → Body-Feld umfang
• Body: Pflicht (--data '<json>')

einstellungen

casa einstellungen festschreibung

Schaltet die Festschreibung der Buchungsperioden ein oder aus: --data '{"propertyId":"<uuid>","aktiv":true}' für ein Objekt, "propertyId": null für die Vorgabe des Mandanten (Vorgabe ist aus). Ausschalten lässt bereits festgeschriebene Perioden gesperrt. Nur ein Mensch mit Admin-Recht (sonst 403); fremdes oder unbekanntes Objekt ⇒ 404. Wiederholungssicher mit --idempotency-key.

casa einstellungen festschreibung --data '<json>'

• Endpunkt: POST /api/einstellungen/festschreibung
• Token nötig: ja
• Body: Pflicht (--data '<json>')

vermoegensbericht

casa vermoegensbericht zeigen

Liest EINEN abgelegten Stand samt seiner Readiness- und Konsistenz-Befunde. --onr <objektId> ist Pflicht: der Stand ist an BEIDEN Achsen verankert, und ein Stand der Nachbargemeinschaft ist über diesen Weg nicht lesbar.

casa vermoegensbericht zeigen <id> [--onr <wert>]

• Endpunkt: GET /api/vermoegensbericht/{id}
• Token nötig: ja
• Argumente: <id> (exakte Stelligkeit — zu viele sind ebenfalls ein Bedienfehler)
• Query-Flags: --onr
• Body: keiner

migration

casa migration vergleich

Liest den centgenauen Abweichungsbericht je Fachbereich zu einem Import-Vorgang: casa.ai rechnet den importierten Bestand nach und stellt ihn gegen die WinCASA-Vergleichswerte des jüngsten Satzes. Cent-Beträge stehen als Ganzzahl-Text. Ein fremder und ein unbekannter Vorgang sehen gleich aus (nicht gefunden).

casa migration vergleich <id>

• Endpunkt: GET /api/migration/{id}/vergleich
• Token nötig: ja
• Argumente: <id> (exakte Stelligkeit — zu viele sind ebenfalls ein Bedienfehler)
• Body: keiner

beschluss

casa beschluss status

Schreibt den Lebenszyklus-Status eines Beschlusses fort (neue Zeile im Verlauf, kein Überschreiben). --data '{"nachStatus":"bestandskraeftig","grund":"Anfechtungsfrist abgelaufen"}' — oder kurz --data '{}' --nach <status> --grund <text>. Unzulässige Übergänge werden abgelehnt; nichtig ist ein Endzustand. Hinweis: bestandskraeftig wird frühestens nach anfechtungsfristEnde gesetzt (steht in objekt beschluss list; Hinweis, keine Sperre).

casa beschluss status <id> [--nach <wert>] [--grund <wert>] --data '<json>'

• Endpunkt: POST /api/beschluss/{id}/status
• Token nötig: ja
• Argumente: <id> (exakte Stelligkeit — zu viele sind ebenfalls ein Bedienfehler)
• Body-Flags: --nach → Body-Feld nachStatus, --grund → Body-Feld grund
• Body: Pflicht (--data '<json>')

einheitengruppe

casa einheitengruppe list

Listet Abrechnungskreise. --status alle\|aktiv\|archiviert (Default aktiv), --propertyId <uuid>.

casa einheitengruppe list [--status <wert>] [--propertyId <wert>]

• Endpunkt: GET /api/einheitengruppe
• Token nötig: ja
• Query-Flags: --status, --propertyId
• Body: keiner

casa einheitengruppe get

Liest EINEN Abrechnungskreis samt Mitgliedschaften. --asOf <YYYY-MM-DD>.

casa einheitengruppe get <id> [--asOf <wert>]

• Endpunkt: GET /api/einheitengruppe/{id}
• Token nötig: ja
• Argumente: <id> (exakte Stelligkeit — zu viele sind ebenfalls ein Bedienfehler)
• Query-Flags: --asOf
• Body: keiner

casa einheitengruppe create

Legt einen Abrechnungskreis an einem aktiven Objekt an. Braucht --data <json> mit propertyId, name, groupKind.

casa einheitengruppe create --data '<json>'

• Endpunkt: POST /api/einheitengruppe
• Token nötig: ja
• Body: Pflicht (--data '<json>')

casa einheitengruppe update

Ändert name/groupKind eines Kreises. Braucht --data <json>. (propertyId ist nicht änderbar.)

casa einheitengruppe update <id> --data '<json>'

• Endpunkt: PATCH /api/einheitengruppe/{id}
• Token nötig: ja
• Argumente: <id> (exakte Stelligkeit — zu viele sind ebenfalls ein Bedienfehler)
• Body: Pflicht (--data '<json>')

casa einheitengruppe archive

Archiviert einen Abrechnungskreis (archived_at statt Löschen).

casa einheitengruppe archive <id>

• Endpunkt: POST /api/einheitengruppe/{id}/archive
• Token nötig: ja
• Argumente: <id> (exakte Stelligkeit — zu viele sind ebenfalls ein Bedienfehler)
• Body: keiner

casa einheitengruppe mitglied add

Nimmt eine Einheit ab Datum in den Kreis auf. --einheit <uuid> --ab <YYYY-MM-DD> [--bis <YYYY-MM-DD>] und --data '{}'.

casa einheitengruppe mitglied add <id> [--einheit <wert>] [--ab <wert>] [--bis <wert>] --data '<json>'

• Endpunkt: POST /api/einheitengruppe/{id}/mitglied
• Token nötig: ja
• Argumente: <id> (exakte Stelligkeit — zu viele sind ebenfalls ein Bedienfehler)
• Body-Flags: --einheit → Body-Feld unitId, --ab → Body-Feld validFrom, --bis → Body-Feld validTo
• Body: Pflicht (--data '<json>')

casa einheitengruppe mitglied beenden

Beendet die Mitgliedschaft einer Einheit zum Stichtag. --einheit <uuid> --bis <YYYY-MM-DD> und --data '{}'.

casa einheitengruppe mitglied beenden <id> [--einheit <wert>] [--bis <wert>] --data '<json>'

• Endpunkt: POST /api/einheitengruppe/{id}/mitglied/beenden
• Token nötig: ja
• Argumente: <id> (exakte Stelligkeit — zu viele sind ebenfalls ein Bedienfehler)
• Body-Flags: --einheit → Body-Feld unitId, --bis → Body-Feld endDate
• Body: Pflicht (--data '<json>')

umlageschluessel

casa umlageschluessel list

Listet Umlageschlüssel. --status alle\|aktiv\|archiviert (Default aktiv), --propertyId/--unitGroupId <uuid>.

casa umlageschluessel list [--status <wert>] [--propertyId <wert>] [--unitGroupId <wert>]

• Endpunkt: GET /api/umlageschluessel
• Token nötig: ja
• Query-Flags: --status, --propertyId, --unitGroupId
• Body: keiner

casa umlageschluessel get

Liest EINEN Umlageschlüssel.

casa umlageschluessel get <id>

• Endpunkt: GET /api/umlageschluessel/{id}
• Token nötig: ja
• Argumente: <id> (exakte Stelligkeit — zu viele sind ebenfalls ein Bedienfehler)
• Body: keiner

casa umlageschluessel create

Legt einen Umlageschlüssel an einem aktiven Objekt an. Braucht --data <json> mit propertyId, keyType, name.

casa umlageschluessel create --data '<json>'

• Endpunkt: POST /api/umlageschluessel
• Token nötig: ja
• Body: Pflicht (--data '<json>')

casa umlageschluessel update

Ändert keyType/name/config. Braucht --data <json>. (Scope über scope, propertyId nicht änderbar.)

casa umlageschluessel update <id> --data '<json>'

• Endpunkt: PATCH /api/umlageschluessel/{id}
• Token nötig: ja
• Argumente: <id> (exakte Stelligkeit — zu viele sind ebenfalls ein Bedienfehler)
• Body: Pflicht (--data '<json>')

casa umlageschluessel scope

Setzt/löst den Abrechnungskreis-Scope. --kreis <uuid> (oder --data '{"unitGroupId":null}' zum Aufheben). HINWEIS: Der Scope wird gespeichert, aber von der Abrechnung noch NICHT ausgewertet — ein gescopter Schlüssel verteilt heute wie ein objektweiter.

casa umlageschluessel scope <id> [--kreis <wert>] --data '<json>'

• Endpunkt: POST /api/umlageschluessel/{id}/scope
• Token nötig: ja
• Argumente: <id> (exakte Stelligkeit — zu viele sind ebenfalls ein Bedienfehler)
• Body-Flags: --kreis → Body-Feld unitGroupId
• Body: Pflicht (--data '<json>')

casa umlageschluessel archive

Archiviert einen Umlageschlüssel (archived_at statt Löschen).

casa umlageschluessel archive <id>

• Endpunkt: POST /api/umlageschluessel/{id}/archive
• Token nötig: ja
• Argumente: <id> (exakte Stelligkeit — zu viele sind ebenfalls ein Bedienfehler)
• Body: keiner

casa umlageschluessel messdienst-import

Importiert externe Messdienst-Festbeträge (CSV oder ARGE-D-Satz-Datei) in einen Umlageschlüssel vom Typ „extern". Braucht --propertyId, --periodFrom, --periodTo, --currency. Die Periode muss EXAKT der Abrechnungsperiode entsprechen, sonst bleibt der Import wirkungslos. Die Datei wird serverseitig geparst, das Format am Inhalt erkannt.

casa umlageschluessel messdienst-import <id> <datei> [--propertyId <wert>] [--periodFrom <wert>] [--periodTo <wert>] [--currency <wert>]

• Endpunkt: POST /api/umlageschluessel/{id}/messdienst-import
• Token nötig: ja
• Argumente: <id>, <datei> (exakte Stelligkeit — zu viele sind ebenfalls ein Bedienfehler)
• Query-Flags: --propertyId, --periodFrom, --periodTo, --currency
• Body: keiner

rechte

casa rechte assign-role

Weist einem User eine Rolle zu. Braucht --data <json> mit userId, roleKey.

casa rechte assign-role --data '<json>'

• Endpunkt: POST /api/rechte/rolle
• Token nötig: ja
• Body: Pflicht (--data '<json>')

casa rechte set-objekt

Setzt eine Objekt-Zuständigkeit. Braucht --data <json> mit userId, propertyId.

casa rechte set-objekt --data '<json>'

• Endpunkt: POST /api/rechte/objekt
• Token nötig: ja
• Body: Pflicht (--data '<json>')

casa rechte revoke-objekt

Entzieht eine Objekt-Zuständigkeit. Braucht --data <json> mit userId, propertyId.

casa rechte revoke-objekt --data '<json>'

• Endpunkt: POST /api/rechte/objekt/entziehen
• Token nötig: ja
• Body: Pflicht (--data '<json>')

vertrag

casa vertrag list

Listet Verträge. --status alle\|aktiv\|beendet (Default aktiv), --objektId <uuid>, --asOf <YYYY-MM-DD>.

casa vertrag list [--status <wert>] [--objektId <wert>] [--asOf <wert>]

• Endpunkt: GET /api/vertrag
• Token nötig: ja
• Query-Flags: --status, --objektId, --asOf
• Body: keiner

casa vertrag get

Liest EINEN Vertrag samt Konditionen-Zeitscheiben und Zahlungen.

casa vertrag get <id>

• Endpunkt: GET /api/vertrag/{id}
• Token nötig: ja
• Argumente: <id> (exakte Stelligkeit — zu viele sind ebenfalls ein Bedienfehler)
• Body: keiner

casa vertrag create

Legt einen Vertrag samt initialer Zahlungs-Zeitscheibe an. Braucht --data <json> mit propertyId, contractNo, mieterPersonId, kaltmieteCents, currency. mieterPersonId ist die MIETPARTEI des Vertrags (seit #1965 Pflicht): die Rolle entsteht in derselben Transaktion, ein Vertrag ohne Mieter ist nicht mehr anlegbar; unbekannt, mandantenfremd oder archiviert ergibt 404. --idempotency-key <key> für wiederholungssichere Anlage.

casa vertrag create --data '<json>'

• Endpunkt: POST /api/vertrag
• Token nötig: ja
• Body: Pflicht (--data '<json>')

casa vertrag end

Beendet einen Vertrag zum Stichtag. Braucht --data '{"endDate":"YYYY-MM-DD"}'.

casa vertrag end <id> --data '<json>'

• Endpunkt: POST /api/vertrag/{id}/end
• Token nötig: ja
• Argumente: <id> (exakte Stelligkeit — zu viele sind ebenfalls ein Bedienfehler)
• Body: Pflicht (--data '<json>')

casa vertrag zahlung set

Wechselt die Konditionen/vereinbarten Zahlungen eines Vertrags als Zeitscheibe. Braucht --data '{"ab":"YYYY-MM-DD","kaltmieteCents":…,"currency":"EUR","payments":[…]}'. --idempotency-key <key> für wiederholungssichere Wechsel.

casa vertrag zahlung set <id> --data '<json>'

• Endpunkt: POST /api/vertrag/{id}/zahlung
• Token nötig: ja
• Argumente: <id> (exakte Stelligkeit — zu viele sind ebenfalls ein Bedienfehler)
• Body: Pflicht (--data '<json>')

casa vertrag personen list

Liest die Kopfzahl-Historie eines Vertrags. --asOf <YYYY-MM-DD> (Stichtag für active).

casa vertrag personen list <id> [--asOf <wert>]

• Endpunkt: GET /api/vertrag/{id}/personen
• Token nötig: ja
• Argumente: <id> (exakte Stelligkeit — zu viele sind ebenfalls ein Bedienfehler)
• Query-Flags: --asOf
• Body: keiner

casa vertrag personen set

Setzt/ändert die Personenzahl eines Vertrags ab Datum (Grenzen einschließlich). --ab <YYYY-MM-DD> und --data '{"personCount":3}'.

casa vertrag personen set <id> [--ab <wert>] --data '<json>'

• Endpunkt: POST /api/vertrag/{id}/personen
• Token nötig: ja
• Argumente: <id> (exakte Stelligkeit — zu viele sind ebenfalls ein Bedienfehler)
• Body-Flags: --ab → Body-Feld validFrom
• Body: Pflicht (--data '<json>')

casa vertrag personen remove

Entfernt eine Personenzahl-Scheibe eines Vertrags; die Vorgängerin deckt die Lücke wieder. Die erste Scheibe bleibt (409 conflict — ändern mit vertrag personen set). Die sliceId liefert vertrag personen list.

casa vertrag personen remove <id> <sliceId>

• Endpunkt: POST /api/vertrag/{id}/personen/{sliceId}/remove
• Token nötig: ja
• Argumente: <id>, <sliceId> (exakte Stelligkeit — zu viele sind ebenfalls ein Bedienfehler)
• Body: keiner

mieterwechsel

casa mieterwechsel

Führt einen Mieterwechsel auf einer Einheit aus (Altvertrag beenden -> Neuvertrag -> Zeitscheiben, eine Transaktion). Braucht --data mit unitId, altVertragId, endDate, contractNo, mieterPersonId, kaltmieteCents, currency. mieterPersonId ist die MIETPARTEI des Neuvertrags (seit #1910 Pflicht): die Rolle entsteht in derselben Transaktion, ein Vertrag ohne Mieter ist nicht mehr anlegbar. Zeitscheiben sind halb-offen: endDate = erster Tag OHNE den Altmieter, startDate = erster Tag MIT dem Neumieter (Default = endDate, nahtlos); früher ist Überlappung (Fehler), später ist Leerstand und braucht leerstandAkzeptiert: true. --idempotency-key <key> macht einen Retry wiederholungssicher.

casa mieterwechsel --data '<json>'

• Endpunkt: POST /api/mieterwechsel
• Token nötig: ja
• Body: Pflicht (--data '<json>')

mandat

casa mandat list

Listet SEPA-Mandate. --status alle\|pending\|active\|revoked\|expired (Default alle), --vertragId/--personId <uuid>.

casa mandat list [--status <wert>] [--vertragId <wert>] [--personId <wert>]

• Endpunkt: GET /api/mandat
• Token nötig: ja
• Query-Flags: --status, --vertragId, --personId
• Body: keiner

casa mandat get

Liest EIN SEPA-Mandat samt Vertrags-/Personen-Bezug.

casa mandat get <id>

• Endpunkt: GET /api/mandat/{id}
• Token nötig: ja
• Argumente: <id> (exakte Stelligkeit — zu viele sind ebenfalls ein Bedienfehler)
• Body: keiner

casa mandat create

Legt ein SEPA-Mandat zu einem Vertrag an (Status pending). Braucht --data <json> mit contractId, mandateRef. --idempotency-key <key> für wiederholungssichere Anlage.

casa mandat create --data '<json>'

• Endpunkt: POST /api/mandat
• Token nötig: ja
• Body: Pflicht (--data '<json>')

casa mandat status

Führt den Mandatsstatus (active\|revoked\|expired). Braucht --data '{"status":"active"}'.

casa mandat status <id> --data '<json>'

• Endpunkt: POST /api/mandat/{id}/status
• Token nötig: ja
• Argumente: <id> (exakte Stelligkeit — zu viele sind ebenfalls ein Bedienfehler)
• Body: Pflicht (--data '<json>')

option

casa option list

Listet Options-Zeilen. --scopeType tenant\|objekt\|einheit\|vertrag, --scopeId <uuid>, --key <k>.

casa option list [--scopeType <wert>] [--scopeId <wert>] [--key <wert>]

• Endpunkt: GET /api/option
• Token nötig: ja
• Query-Flags: --scopeType, --scopeId, --key
• Body: keiner

casa option get

Löst den effektiven Wert eines Schlüssels auf. --key <k> (Pflicht), --objektId/--einheitId/--vertragId <uuid>.

casa option get [--key <wert>] [--objektId <wert>] [--einheitId <wert>] [--vertragId <wert>]

• Endpunkt: GET /api/option/effective
• Token nötig: ja
• Query-Flags: --key, --objektId, --einheitId, --vertragId
• Body: keiner

casa option set

Setzt/überschreibt eine Option. Braucht --data '{"scopeType":"tenant\|objekt\|einheit\|vertrag","scopeId":"<uuid>","key":"...","value":<json>}' (scopeId nur für nicht-tenant-Scopes).

casa option set --data '<json>'

• Endpunkt: POST /api/option
• Token nötig: ja
• Body: Pflicht (--data '<json>')

onboarding

casa onboarding

Geführtes Onboarding: Objekt → Bankverbindungen → Gebäude → Einheiten → Verträge → Plausi-Gate. --file <plan.json> (sonst interaktiv), --protokoll <pfad> macht den Lauf wiederaufsetzbar. Ausgabe ist ein JSON-Protokoll des Angelegten.

casa onboarding [--file <wert>] [--protokoll <wert>]

• Endpunkt: POST /api/objekt (Einstieg der Sequenz)
• Ablauf: casa objekt create → casa bank create → casa gebaeude create → casa einheit create → casa vertrag create → casa objekt check
• Flow-Flags: --file, --protokoll
• Token nötig: ja
• Body: keiner