Türwerk

Die eine Auskunft. Ohne Angabe das Lagebild: was ist überfällig, was wird bald fällig, wo stehen Berichte aus. Mit 'objekt' die Liegenschaft mit ihrem ganzen Bestand in Laufreihenfolge, den Checklisten ihrer Türtypen und den letzten Terminen. Mit 'objekt' und 'tuer' die Geschichte dieser einen Tür über die Jahre. Das ist die Antwort auf 'was ist los?', 'gibt es das Objekt schon?' und 'was war letztes Mal an Tür 12?'.

Beginnt den Termin an einem Objekt — einmal, ganz am Anfang. Kennt der Server das Objekt nicht, legt er es an: die erste Wartung ist die Bestandsaufnahme. Läuft am selben Tag schon eine, wird sie fortgesetzt statt verdoppelt; ein abgebrochenes Gespräch kostet also nichts. Die Antwort bringt alles mit, was zum Diktieren nötig ist: die fälligen Türen in Laufreihenfolge, die Checklisten der hier vorkommenden Türtypen (damit 'Punkt 8' etwas bedeutet) und was beim letzten Mal nicht in Ordnung war. Danach nur noch 'tuer_erfassen'.

Schreibt eine diktierte Tür sofort weg — nach JEDER Tür einmal aufrufen, nichts im Gespräch puffern: bricht es ab, ist alles Geschriebene sicher. Mehrere Türen dürfen in einem Aufruf stehen, wenn sie in einem Zug diktiert wurden. Standard ist: alles in Ordnung. Nur Abweichungen als 'checks' nennen, z. B. {"8":"nio"}. Bewertungen: nio = nicht in Ordnung · sb = siehe Bemerkung (Text nach 'hinweise') · nz = nicht zutreffend. Eine Abweichung heißt: die Tür hat NICHT bestanden — das ergibt sich von selbst, niemand muss es extra sagen. 'Tür 12' meint die Tür Nr. 12 dieses Objekts, nicht die zwölfte des Tages; eine unbekannte Nummer wird angelegt ('Tür 12 ist neu — lege ich an'). Eine schon erfasste Nummer wird überschrieben, das ist der Weg für Korrekturen. Fehlt einer neuen Tür eine Pflichtangabe ihres Türtyps, wird trotzdem gespeichert und die Lücke gemeldet — gefragt wird am Ende, nicht mitten im Rundgang.

Auf 'Fertig': liest alles zurück (je Tür Ort, Abweichungen im Klartext, Ergebnis), nennt die fälligen Türen, die noch fehlen, UND erzeugt in demselben Zug die Berichte und den Sammelbericht. Ein Aufruf, kein Dreisprung. Kommt 'fertig: false' zurück, reichte die Rechenzeit nicht: einfach noch einmal aufrufen. Erzeugt wird nur, wo sich etwas geändert hat — zweimal aufrufen macht keine zweite Version. Die Berichte liegen danach getrennt nach bestanden und Nachbesserung auf der Objektseite. Mit 'abbrechen' platzt der Termin stattdessen; bereits erfasste Türen bleiben erhalten.

Der Weg vor der Wartung, am besten im Büro. Ein Aufruf nimmt entgegen, was schon bekannt ist, und meldet zurück, was noch fehlt — es wird nicht Frage für Frage abgefragt, das Fragen ist deine Sache. • Stammdaten: Adresse, Betreiber, Ansprechpartner mit Telefon, Intervall und vor allem 'zugang' — wie man reinkommt ('Schlüssel beim Hausmeister'). Das ist das Feld, das die vergebliche Anfahrt verhindert. • Türtypen: was für alle Türen einer Art gleich ist, samt eigener Checkliste. Die gängigen liegen im Vorrat und entstehen beim ersten Gebrauch — 'stand' zeigt sie. • Bestand: die Türen. Aus einer Türenliste oder einem Grundriss liest DU die Zeilen und gibst sie hier ab; Türtypen, Geschosse, Nummern und Laufreihenfolge legt der Server dabei selbst an. Daraus werden noch keine Türen: erst 'freigeben' macht welche daraus, und genau das muss ein Mensch entschieden haben. Den 'bericht' aus der Antwort vorlesen und die Freigabe einholen. Der Aufruf darf sich wiederholen — schon Bekanntes kommt nicht doppelt.

Berichtigt, was schon steht — Objekt, eine einzelne Tür, einen Türtyp samt Checkliste oder die eigenen Standardwerte. Nur die genannten Felder werden angefasst. Stammdatenänderungen wirken auf alle Berichte, die danach neu erzeugt werden; um sie in bestehende zu bekommen, danach 'wartung_fertig' mit alle_neu. Eine falsch diktierte Prüfung braucht das hier nicht: 'tuer_erfassen' mit derselben Nummer überschreibt sie.