Wie Organisation, Objekt, Einheiten, Eigentümer, Portalzugänge, Dokumente, Beschlüsse, Wirtschaftspläne, Abrechnungen und Kommunikation als System zusammenarbeiten.
Stand 08.07.2026. Diese Hilfe ist als Arbeitsreferenz gedacht: ruhig lesbar, nah am Portal und so formuliert, dass neue Eigentümer und Verwaltungsteams den Sinn der Plattform schnell verstehen.
Organisation → Objekt → Einheit → Person → Dokument → Vorgang. Alles, was im Portal passiert, sollte an mindestens einem dieser Kontexte hängen.
Für die Verwaltung ist Trentivo als operative Zentrale gedacht. Die Plattform soll nicht einzelne Masken nebeneinanderstellen, sondern Verwaltungsarbeit entlang einer sauberen Struktur führen: Organisation, Objekt, Einheiten, Personen, Dokumente, Vorgänge, Beschlüsse und Finanzen.
Gerade bei Neubau, Übergangsverwaltung oder erster Inbetriebnahme entstehen viele parallele Aufgaben. Ohne System werden daraus E-Mails, Tabellen, Notizen und Ordner. Trentivo soll diese Arbeit in objektbezogene Pläne, Aufgaben, Dokumentbedarfe, Beschlussvorlagen und Freigaben überführen.
Die wichtigste Regel: Fachliche Daten und Benutzerzugänge sind getrennt. Ein Eigentümerdatensatz beschreibt die Person im Verwaltungszusammenhang. Der Portalzugang ist ein Access-/Benutzerthema und wird zentral gesteuert.
Alles, was Benutzer, Rollen, Einladungen, Revokes oder Löschungen betrifft, gehört zentral in Access/Benutzerverwaltung. Fachseiten dürfen Status anzeigen, eine Einladung anstoßen oder zur Benutzerverwaltung verlinken, aber keine eigene parallele Benutzerlogik aufbauen.
Ein Vorgang ohne Bezug wird später schwer auffindbar. Deshalb sollte ein Vorgang möglichst an Objekt, Einheit, Person, Dokument, Beschluss, Wirtschaftsplan oder Abrechnung hängen.
Eine Unterlage in der Datenbank ist nicht automatisch portal-sichtbar. Gerade Abrechnungen, Salden, persönliche Daten und Eigentümerunterlagen brauchen bewusste Freigabe. Objektweit bedeutet nicht automatisch für alle sichtbar.
Wenn neue Funktionen entstehen, muss die Hilfe mitwachsen. Sonst ist das Portal technisch besser, aber für Nutzer unklarer. Jede größere Änderung sollte deshalb die Guides aktualisieren.
Objektstammdaten, Adresse, Verwaltungsart, Einheiten und Grunddaten müssen stimmen. Diese Daten sind die Basis für Eigentümerzuordnung, Dokumente, Portalzugang, Wirtschaftspläne und spätere Abrechnungen.
Alle Einheitstypen sollten strukturiert aus der Objektdatenbank kommen: Wohnungen, TG-Plätze, Stellplätze, Keller, Gewerbe, Nebenflächen oder weitere Typen. Freitext sollte nur dort verwendet werden, wo es fachlich nötig ist.
Bei der Eigentümeranlage wird das Objekt gewählt und anschließend werden die zugehörigen Einheiten hinzugefügt. Bis zu 48 Einheiten pro Eigentümer sind vorgesehen, damit auch komplexe Zuordnungen möglich bleiben.
Bei der Eigentümeranlage kann ein Portalzugang direkt mit Einladung angestoßen werden. Danach gehören Revokes, Benutzerstatus und Löschung in die zentrale Benutzerverwaltung.
Schon bei der Einrichtung sollte klar sein, welche Dokumente objektweit, einheitenbezogen oder eigentümerspezifisch sind. Das verhindert spätere Datenschutz- und Sichtbarkeitsprobleme.
Für Neubau und Übergangsverwaltung sollte die Objekt-Verwaltungszentrale mit Standardaufgaben arbeiten: Konto, Versicherung, Hausstrom, Wasserzähler, Rauchmelder, Aufzug/Tor, Wartung, Hausmeister, Müllplatz, Schlüssel, Eigentümerdaten, Wirtschaftsplan-Grundlagen und Beschlussvorlagen.
Eigentümerdaten werden nicht nur erfasst, sondern bestätigt. Die Einladung bittet um Prüfung von Kontaktdaten, Anschrift, Postadresse, privaten Daten und Einheiten. Bestätigungen werden gespeichert und später im Profil sichtbar.
Kostenarten, Umlageschlüssel und Vorschüsse müssen objektbezogen aufgebaut werden. Der Wirtschaftsplan kann objektweit gelten, während Einzelansichten je Eigentümer oder Einheit entstehen.
Die Abrechnung braucht eine andere Sichtbarkeitslogik als ein allgemeiner Wirtschaftsplan. Gesamtunterlagen können objektbezogen sein, Einzelabrechnungen und persönliche Salden müssen eigentümerspezifisch freigegeben werden.
Ein Beschluss sollte nicht isoliert bleiben. Nach Beschlussfassung entstehen oft Aufgaben: Vertrag abschließen, Angebot einholen, Dienstleister beauftragen, Zahlung vorbereiten oder Dokument veröffentlichen. Trentivo soll diesen Weg sichtbar machen.
Nachrichten sollten möglichst nicht ohne Bezug geführt werden. Eine Frage zur Abrechnung gehört zur Abrechnung, eine Frage zur Einheit gehört zur Einheit, ein Hinweis zur Adresse gehört zum Eigentümerprofil. Das ist die Grundlage für spätere Historie und Audit.
Überblick über offene Vorgänge, Aufgaben, neue Eingänge und wichtige Systemhinweise. Sollte nicht überladen werden, sondern die nächsten Entscheidungen sichtbar machen.
Zentrale Objektverwaltung mit Stammdaten, Einheiten, Eigentümern, Dokumenten, Ereignissen, Aufgaben, Beschlüssen, Plänen und Abrechnungen.
Fachliche Struktur aller verwalteten Einheiten. Wichtig für Eigentümerzuordnung, Mieterbezug, Abrechnung, Dokumente und Portalrechte.
Fachlicher Datensatz zur Person oder Partei. Enthält Stammdaten, Bestätigungsstatus, Einheitenbezug und Hinweise. Benutzerverwaltung bleibt getrennt.
Zentraler Bereich für Einladungen, Portalzugänge, Rollen, Revokes, Benutzerstatus und Löschungen. Keine parallele Benutzerlogik auf Fachseiten.
Bewerber- und Interessentenflow für Vermietungsprozesse. Kann später mit SEV, Mietverwaltung und Einheiten verknüpft werden.
Ablage mit Kategorie, Typ, Status, Objekt-/Einheiten-/Personenbezug und Freigabelogik.
Beschlussvorlagen, Umlaufbeschlüsse, Abstimmungen, Ergebnisse, Dokumente und spätere Umsetzung.
Planung von Kosten, Vorschüssen und Umlagebasis. Grundlage für Hausgeld und Beschlussfassung.
Erfassung tatsächlicher Kosten, Verteilung, Salden, Einzelabrechnung, PDF und Freigabe ins Portal.
Nachrichten und Vorgänge mit Bezug zu Objekt, Einheit, Dokument, Beschluss oder Abrechnung.
Weil gleiche Fachobjekte unterschiedlich sichtbar sein können. Ein Wirtschaftsplan kann für alle Eigentümer eines Objekts relevant sein, eine Einzelabrechnung dagegen nur für einen Eigentümer. Diese Logik darf nicht nur in der Oberfläche stecken, sondern muss in der Daten- und Rechtebasis abbildbar sein.
Die Eigentümergruppe ist ein eigener fachlicher Zusammenhang. Eigentümer und Einheiten können zuerst sauber erfasst werden. Danach kann die Gruppe erstellt, dem Objekt zugewiesen und mit Eigentümern befüllt werden.
Jeder Patch, der Menüs, Workflows, Rollen, Freigaben oder Datenmodelle ändert, sollte die Guides mitpatchen. Die Guide-Version macht sichtbar, wann diese Referenz zuletzt fachlich angepasst wurde.
Dev und Prod müssen getrennte Datenbanken haben. Produktive Eigentümer-, Mieter- und Objektdaten dürfen nicht mit Testdaten vermischt werden. Ebenso wichtig sind Backups, klare Rollen, saubere Freigaben und nachvollziehbare Änderungen.
Guides für Eigentümer, Verwaltung, Rollen und Glossar bleiben miteinander verknüpft.