Das Büro ist vermietet, die Rechnung gestellt, das Geld fehlt. Drei verschiedene Zustände

In Alistera CRM habe ich Fläche, Vertrag, Rechnung und Zahlung getrennt. Ein Büro kann belegt und die Rechnung gestellt sein, obwohl das Geld noch nicht eingegangen ist. Um den Geschäftsbetrieb zu verstehen, müssen diese Zustände verknüpft werden und trotzdem unterscheidbar bleiben.

Für Alistera habe ich ein separates operatives CRM gebaut. Es enthält einen Flächenkatalog, Verträge, Rechnungen, Zahlungen, Planung und Zugriffsverwaltung. Es ist ein eigenständiges Produkt neben öffentlicher Website und Spiel: Jedes hat seine Aufgabe und seine Daten.

Dieser Bildschirm zeigt fiktive Büros, ihren Zustand und ihre Mietbeziehungen. Er ist ein funktionierendes Beispiel der Katalogoberfläche, keine aktuelle Auskunft über verfügbare Alistera-Flächen.

Bürokatalog

Archivierte Oberfläche · Demodaten

Eine Fläche existiert in der Zeit

Der Katalog umfasst 93 Einträge: 71 Büros, 12 Schreibtische und 10 Gemeinschaftsflächen. Eine Liste allein reicht aber nicht. Die Frage „Ist die Fläche frei?“ braucht ein Datum oder einen Zeitraum. Dasselbe Büro kann heute belegt und in einem Monat verfügbar sein.

Darum ist der Vertrag an ein Zeitintervall gebunden; Überschneidungen müssen bei Änderungen geprüft werden. Der Kalender hilft Menschen, Konflikte zu sehen. Die serverseitige Prüfung verhindert Konflikte durch zwei gleichzeitig geöffnete Tabs.

Eine Rechnung ist eine Aufforderung, eine Zahlung ein Ereignis

Das Finanzmodell trennt Rechnungsbetrag, bestätigte Zahlung und deren Zuordnung. Eine Teilzahlung muss eine Rechnung nicht vollständig ausgleichen. Eine Überweisung muss womöglich auf mehrere Verpflichtungen verteilt werden. Ein Feld „Status“ kann diese Beziehungen nicht verlässlich ersetzen.

Unten sind Demorechnungen und Zahlungsdatensätze geöffnet. Sie zeigen, wie die Oberfläche Verpflichtungen und Geldeingänge trennt, ohne echte Finanzdaten zu verwenden.

Rechnungen und Zahlungen

Archivierte Oberfläche · Demodaten

Geld wird als ganze Zahl in Fils gespeichert. Das vermeidet typische Überraschungen der Gleitkommaarithmetik beim Addieren und Vergleichen. Diese Entscheidung repariert für sich genommen keine Buchhaltung; sie beseitigt eine unnötige Fehlerquelle.

Die Historie finanzieller Aktionen bleibt erhalten. Eine Korrektur muss erklären, was geändert wurde, statt den früheren Stand zu verleugnen. Ein Unternehmen braucht manchmal die unbequeme Wahrheit über gestern statt einer perfekt geglätteten Tabelle für heute.

Mit der Oberfläche endet die Arbeit nicht

Die Anwendung nutzt React, Vite, Cloudflare Worker und D1. Anmeldung und Profil sind mit dem Rechtesystem verbunden; die Berechtigung wird an der API geprüft, nicht nur durch versteckte Buttons. Planung lässt sich als Liste, Kanban-Board oder Gantt-Diagramm ansehen. Die Ansichten unterscheiden sich, die Aufgaben müssen dieselben bleiben.

Ein implementiertes CRM beweist noch nicht, dass das ganze Unternehmen seinen Alltag bereits darin abwickelt. Zum geprüften Stand kann ich Modell, Funktionen und technische Prüfungen zeigen; Nutzungszahlen oder Zeitersparnisse erfinde ich nicht.

In dieser Phase sind Katalog, Verträge, Finanzdatensätze und Planung umgesetzt. Sie lassen sich mit Demobüros und -rechnungen ansehen. Die vollständige Einführung in den Alltag und das Messen des Teamnutzens sind eine eigene Phase; deshalb gibt es hier keine Nutzungs- oder Zeitersparniszahlen.

Verwandte Beiträge: Kontrolle und Berichtsversionen · Öffentliche Website von Alistera.