Ticket Billing – Support und Zeitabrechnung auf ERPNext 16 (AGPL-3.0)

Ich habe eine Ticket-App für ERPNext gebaut und jetzt veröffentlicht. Sie
zielt auf den Fall, dass Supportanfragen per E-Mail hereinkommen und die
dafür erfasste Zeit am Ende auf einer Rechnung landen muss.

Vorweg zum Reifegrad: Die App ist lokal entwickelt und getestet, unter
anderem mit echtem Mailverkehr in beide Richtungen. Im Produktivbetrieb läuft
sie noch nicht. Rückmeldungen sind mir deshalb besonders willkommen.

Keine eigenen Ticket-Doctypes. Die App erweitert Issue und Timesheet
um Custom Fields, statt eigene Dokumenttypen einzuführen. Der Weg
Timesheet → Sales Invoice bleibt genau der, den ERPNext vorgibt. Die Felder
entstehen in Code bei after_install und after_migrate, nicht als Fixture –
Fixtures auf fremden Doctypes brechen, sobald ERPNext dort etwas ändert.

Die Abteilung kommt aus dem Postfach. Je Abteilung ein Email Account mit
dem Feld tb_department; das empfangende Postfach entscheidet, wem der
Vorgang gehört. Zwei Dinge waren dafür nötig: ein Property Setter für
Issue.recipient_account_field, den ERPNext nicht setzt, und der Vorrang des
Postfachs vor dem, was schon im Feld steht. Frappe belegt Verweisfelder aus
den User Permissions vor – ein Ticket, das ein Mitarbeiter abruft, landete
sonst in seiner Abteilung.

Rechte auf drei Ebenen, ausnahmslos serverseitig: DocPerms als Obergrenze,
User Permissions auf Department, gespiegelt aus Employee.department, und
permission_query_conditions / has_permission für die zeilenweise
Einschränkung. Jeder Whitelisted-Endpunkt prüft zusätzlich selbst. Die
Vue-Oberfläche blendet nur aus, was ohnehin keine Daten liefern würde.

Austauschbare Zuweisungsregel. Ein kleines Verzeichnis mit der
Schnittstelle select(issue, candidates); die mitgelieferte Regel nimmt den
Mitarbeiter mit den wenigsten offenen Tickets. Round Robin wäre eine Datei
plus eine Importzeile.

Zeiterfassung im Vier-Augen-Prinzip. Der Timer liegt auf dem Server
(eindeutiger Index auf den Mitarbeiter, also genau einer), Einträge sind
zunächst Entwurf, gebucht wird durch die Abteilungsleitung. Gebucht heißt
unveränderlich – dafür sorgt Frappe selbst, ein zweiter Sperrmechanismus wäre
nur eine weitere Fehlerquelle.

Dazu: Kennzahlen-Dashboards mit Excel-Export, Realtime über Benutzerräume mit
serverseitig bestimmter Empfängerliste, Deutsch und Englisch durchgängig, und
Demo-Daten, die jeden angelegten Satz mitschreiben – entfernt wird
ausschließlich, was die Installation selbst erzeugt hat.

Repos:

Beide READMEs liegen auf Deutsch und Englisch vor und begründen die
Abweichungen vom ERPNext-Standardverhalten.

Gruß Sascha