Betrieb

Aufträge & Prozesse

Die Admin-Auftragsansicht zeigt alle Aufträge über alle Organisationen hinweg. Sie können Aufträge erstellen, Dienste zuweisen, Prozesse verknüpfen und Zeit erfassen. Prozessvorlagen können unter Vorlagen für die organisationsübergreifende Wiederverwendung verwaltet werden.

Jeder eingereichte Standard-Auftrag braucht vor dem Abschluss eine Einstufung. Sie entscheidet, wer zahlt, und steuert den Angebotsprozess:

Aufträge mit Dienstbezug laufen durch die Warteschlange des Dienstes: ein aktiver Auftrag gleichzeitig, weitere warten im Status Warteschlange und rücken automatisch nach. Wird ein Auftrag abgeschlossen oder storniert, öffnet sich der nächste wartende Auftrag.

Meldungen & Feedback

Von Kunden gemeldete Störungen erscheinen im Meldungsbereich mit Prioritätsstufen und vordefinierten Labels (Dienst nicht verfügbar, Login-Probleme etc.). Sie können aus Meldungen Support-Aufträge erstellen, um strukturiert nachzuverfolgen. Benutzerfeedback wird separat erfasst und kann als geprüft markiert werden.

Hintergrundjobs

Die Plattform führt geplante Hintergrundjobs über BullMQ mit Redis aus. Das Bull Board Dashboard unter /administration/bull-board zeigt Status, Verlauf und Metriken aller Jobs. Fehlgeschlagene Jobs werden bis zu 3-mal mit exponentiellem Backoff wiederholt.

Kommunikationsprotokoll

Das Kommunikationsprotokoll unter Administration führt jede ausgehende Mail als eine Zeile je Zustellkette: alle Versuche derselben Mail an denselben Empfänger, getragen vom jüngsten. Das Öffnen einer Zeile zeigt Empfänger, Betreff, Vorlage, jeden Versuch mit seinem Ergebnis und die Antwort des Providers im Wortlaut, mit einer Fehlerklasse, die sagt, ob ein erneuter Versuch helfen kann.

Owner und Operatoren können eine Mail aus der Seitenansicht erneut senden. Der erneute Versand geht an den Empfänger, den die Kette immer hatte, mit dem Inhalt, den sie beim ersten Versand trug; das PDF einer Rechnung, eines Angebots, einer Mahnung oder eines Belegs wird aus dem Datensatz neu erzeugt. Es gibt kein Adressfeld: Eine falsche Adresse wird an der Organisation korrigiert, und die Mail wird von dort neu ausgelöst. Entwickler sehen das gesamte Protokoll, aber kein Sende-Element.

• Der Bestätigungsdialog zitiert die letzte Antwort des Providers, damit Sie mit dem Fehler vor Augen entscheiden.
• Einen vorübergehenden oder nicht erkannten Fehler versucht die Plattform selbst erneut: insgesamt fünf Versuche, mit 5 Minuten, 30 Minuten, 2 Stunden und 6 Stunden Abstand. Die Seitenansicht sagt, wann der nächste Versuch fällig ist, oder dass die Plattform aufgegeben hat und die Kette auf Sie wartet. Ein dauerhafter Fehler, Auth-Mails und alles, was vor der Einführung der Wiederholung fehlgeschlagen ist, wird nie automatisch erneut versucht.
• Ein erneuter Versand erscheint als weiterer Versuch derselben Kette, nie als neue Zeile.
• Erneut senden aus dem Protokoll oder neu senden aus dem Datensatz? Senden Sie aus dem Protokoll erneut, wenn die E-Mail richtig war und nur nicht ankam: derselbe Inhalt an dieselbe Adresse, angehängt an die bereits bestehende Kette. Senden Sie aus der Rechnung neu, wenn die E-Mail neu erzeugt werden muss, weil nichts aufbewahrt wurde, woraus sie sich rendern ließe, weil sich die Zahlen geändert haben oder weil sich die Rechnungsempfänger geändert haben. Das ist eine neue E-Mail in einer eigenen Zustellung, und sie lässt die fehlgeschlagene als Beleg dessen stehen, was passiert ist. Nur Rechnungen bieten das an; ein Angebot, ein Beleg oder eine Mahnung wird aus dem Protokoll erneut gesendet.
• Der Filter Typ grenzt das Protokoll auf Rechnungen, Angebote, Zahlungen, Mahnungen, Belege, Bestätigungsmails für Kanäle, Mitglieder-Mails, Inhaltsmeldungen oder Sperrungen ein; die Kanalbestätigung ist Auth-Mail und wird bei dieser Auswahl auch ohne den Schalter Auth-Mail angezeigt. Daneben grenzt der Filter Organisation das Protokoll auf einen Kunden ein, sodass sich die Einladung, die für ihn hinausging, auch ohne den Empfänger finden lässt. Die Referenz öffnet die Rechnung oder das Angebot, um das es in einer Mail geht; bei der Kontakt- oder Rechnungsadresse einer Organisation öffnet sie die Organisation, und die persönliche Adresse eines Mitglieds hat hier keine Seite.
• Jede Mail, die die Plattform versendet, steht im Protokoll, Anmeldelinks, Verifizierungs- und Passwort-Zurücksetzen-Mails eingeschlossen. Jede trägt die Kategorie ihrer Vorlage: geschäftlich, Benachrichtigung, Auth oder System. Auth-Mails sind standardmäßig ausgeblendet, damit sie den Rest nicht überdecken; der Schalter Auth-Mails in der Filterleiste zeigt sie an, und die Wahl von Auth im Kategoriefilter zeigt nur sie. Auth-Mails werden protokolliert und sonst nichts: Es wird kein Inhalt aufbewahrt, und sie werden weder automatisch wiederholt noch erneut gesendet.
• Ein erneuter Versand wird mit angezeigtem Grund abgelehnt, solange der letzte Versuch noch nicht zurück ist, bei Anmelde-Mails und der Test-Mail, wenn nichts aufbewahrt wurde, woraus sich die Mail erzeugen ließe, und wenn der Datensatz sie nicht mehr trägt: eine stornierte oder gelöschte Rechnung, eine bezahlte Rechnung hinter einer Mahnung, ein zurückgezogenes oder abgelaufenes Angebot, eine gelöschte Organisation. Eine Einladung wird aus einem eigenen Grund abgelehnt: Ihr Link ist einmalig und wird nicht aufbewahrt, das Mitglied wird deshalb aus der Mitgliederliste der Organisation neu eingeladen.
• Wie lange eine Mail im Protokoll bleibt, richtet sich danach, wofür sie Beweis ist. Eine Rechnung, ein Beleg, ein Angebot oder eine Mahnung und jede Mail dazu wird 6 Jahre ab Ende des Jahres aufbewahrt, in dem sie gesendet wurde: ein Handelsbrief ist nach § 257 HGB und § 147 AO so lange aufzubewahren, und eine Mahnung ist selbst einer. Sonstige Benachrichtigungs-, Rechts- und Systemmails werden 4 Jahre ab Jahresende aufbewahrt, die regelmäßige Verjährungsfrist der §§ 195 und 199 BGB. Auth-Mails, die nur eine Adresse und einen Zeitpunkt tragen, werden nach 90 Tagen entfernt: Nach der Speicherbegrenzung des Art. 5 Abs. 1 lit. e DSGVO bleiben sie nicht länger, als die Sicherheitsdiagnose sie braucht. Eine Kette wird als Ganzes entfernt, sobald ihr letzter Versuch so alt ist. Der Inhalt, aus dem eine Mail erzeugt wurde, wird nach 30 Tagen gelöscht, der Eintrag selbst bleibt, und ab dann kann die Kette nicht mehr aus dem Protokoll gesendet werden.
• Jeder Versuch hält fest, welche Version der Plattform die Mail erzeugt hat; das Seitenblatt zeigt sie. So lässt sich der Wortlaut, den ein Kunde erhalten hat, im Streitfall rekonstruieren.