HandwerkCloud: vom Kunden über das Angebot zum Auftrag

Ausgangslage

Angebote entstanden in einem Programm, Aufträge in einem zweiten. Wurde ein Angebot angenommen, tippte jemand dieselben Daten ein zweites Mal ab. Das ist lästig, aber vor allem ist es eine Fehlerquelle: sobald zwei Systeme dieselbe Anschrift führen, weichen sie irgendwann voneinander ab.

Das größere Problem lag bei den Bildern. Fotos von der Baustelle lagen auf den Telefonen der Monteure, Skizzen entstanden auf Papier und wurden abfotografiert, wenn überhaupt. Die Aufnahmen, auf die sich ein Angebot bezog, fanden ihren Weg zum Auftrag gar nicht erst. Wer auf der Baustelle wissen wollte, wie die Montage gedacht war, rief im Büro an.

Der Ablauf in der Anwendung

1. Kunde anlegen. Stammdaten mit Anschrift, die später in Angebot und Auftrag übernommen werden.

2. Angebot erstellen. Das Angebot hängt am Kunden. Fotos und Skizzen lassen sich bereits hier anhängen, nicht erst später.

3. Aus dem Angebot wird der Auftrag. Ein Klick, und Kunde, Termine und sämtliche Medien sind übernommen. Genau hier lag vorher die doppelte Erfassung.

4. Vor Ort dokumentieren. Auf dem Tablet im Fahrzeug wird die Baustelle fotografiert und die Montage direkt auf dem Bildschirm skizziert, mit Finger oder Stift.

5. Unterlagen mitnehmen. Alle Fotos und Skizzen eines Auftrags lassen sich als ZIP-Archiv herunterladen, damit die Monteure sie auch ohne Empfang dabei haben.

Worauf es bei der Umsetzung ankam

Rechte je Datensatz, nicht je Seite. Jeder sieht und bearbeitet nur, was er selbst angelegt hat, Administratoren alles. Listen filtern bereits in der Datenbankabfrage, einzelne Datensätze laufen zusätzlich über eine eigene Prüfung. Eine fremde ID in der Adresszeile genügt damit nicht, um an fremde Daten zu kommen. Fotos und Skizzen erben ihre Zuordnung von Angebot oder Auftrag.

Medien an beiden Seiten, ohne Dopplung. Ein Foto hängt gleichzeitig am Angebot und am daraus entstandenen Auftrag. Der Monteur sieht am Auftrag genau das, was zum Angebot gehörte, und die Datei liegt trotzdem nur einmal auf der Platte.

Zeichnen mit Maus, Finger und Stift. Die Zeichenfläche arbeitet mit Pointer Events, damit alle drei Eingabearten denselben Weg im Code gehen. Getrennte Behandlung von Maus und Touch ist die übliche Stelle, an der so etwas auf einem Gerät funktioniert und auf dem nächsten nicht.

Eine Suche über alles. Kunden, Angebote und Aufträge, durchsuchbar nach Name, Postleitzahl oder Ort. Die Suchbedingungen sind bewusst gruppiert, bevor die Rechteprüfung greift. Flach aneinandergehängt wäre das ein klassischer Weg, über eine ODER-Verknüpfung fremde Datensätze sichtbar zu machen.

Warum ohne Frontend-Framework

Die Oberfläche ist Twig mit einem eigenen CSS-System und einfachem JavaScript, ohne Build-Schritt. Für eine Anwendung aus Formularen, Listen und einer Zeichenfläche bringt ein Framework hier keinen Vorteil, kostet aber dauerhaft Pflege bei jedem Versionswechsel.

Der Betrieb braucht damit nichts außer PHP. Das ist bei einem Handwerksbetrieb ohne eigene IT-Abteilung kein Detail, sondern die Voraussetzung dafür, dass die Anwendung in fünf Jahren noch läuft.

Abgesichert ist das Ganze mit PHPUnit und Symfony BrowserKit, die Tests laufen bei jedem Push über GitHub Actions.

Zu den Bildschirmfotos

Die Aufnahmen stammen aus einer bereinigten Fassung. Kundenbranding, Produktivadressen und echte Daten sind entfernt und durch eine neutrale Identität und erzeugte Demodaten ersetzt. Der Auftraggeber wird nicht genannt, die Branche schon, damit die Referenz überhaupt etwas aussagt.

Ein öffentliches Repository gibt es zu diesem Projekt bewusst nicht: Quellcode und Dokumentation gehen mit der Abnahme an den Auftraggeber über, und dazu passt kein einsehbarer Spiegel desselben Codes.