Kapitel 8 – Kundenabrechnung (Customer Usage Data)
Ziel dieses Kapitels
Nachdem sämtliche Ladevorgänge (Gridware Usages) erfolgreich aus Gridware synchronisiert wurden, beginnt die eigentliche kaufmännische Verarbeitung innerhalb von ERPNext.
Da ein einzelner Ladevorgang in der Regel nicht direkt fakturiert wird, müssen zunächst alle abrechnungsrelevanten Nutzungen eines Kunden innerhalb eines Abrechnungszeitraums zusammengefasst werden.
Hierfür wurde der Custom DocType Customer Usage Data entwickelt. Er bildet die erste kaufmännische Aggregation der technischen Gridware-Daten und dient als Grundlage für die spätere Erstellung von Kundenrechnungen.
8.1 Fachlicher Hintergrund
Ein Customer Usage Data Datensatz fasst mehrere einzelne Gridware Usages eines Kunden innerhalb einer Billing Period zusammen.
Während ein Gridware Usage lediglich einen einzelnen Ladevorgang beschreibt, repräsentiert Customer Usage Data bereits einen kaufmännischen Abrechnungsdatensatz.
8.3 Warum wurde Customer Usage Data entwickelt?
Die technische Struktur der Gridware-Daten eignet sich nicht direkt für eine Rechnungsstellung.
Ein Kunde kann innerhalb eines Monats:
- zahlreiche Ladevorgänge durchführen,
- mehrere Verträge besitzen,
- unterschiedliche Vertragsarten nutzen,
- verschiedene Zahlungsmethoden verwenden.
Eine Rechnung pro Ladevorgang wäre weder fachlich noch kaufmännisch sinnvoll.
Aus diesem Grund werden sämtliche abrechnungsrelevanten Ladevorgänge zunächst zu Customer Usage Data aggregiert.
8.4 Rolle innerhalb der Systemarchitektur
Customer Usage Data bildet die Schnittstelle zwischen den technischen Nutzungsdaten und der eigentlichen Rechnungsstellung.
Gridware Usage
↓
Customer Usage Data
↓
Sales Invoice
↓
SEPA / Payment Entry8.5 Aggregationslogik
Alle Gridware Usages werden nach definierten Regeln zu einem Customer Usage Data Datensatz zusammengefasst. Die genaue Aggregationslogik richtet sich nach den jeweiligen Vertragsmodellen und Abrechnungsregeln.
Typische Kriterien sind:
- Billing Period
- Kunde
- Vertrag
- Company
- Contract Type
- is reimbursement (Dienstwagen-Fall)
Die Aggregation sorgt dafür, dass sämtliche zusammengehörenden Nutzungen gemeinsam fakturiert werden.
8.6 Aufbau des Customer Usage Data Doctypes
| Bereich | Inhalt |
|---|---|
| General Information | Customer, Billing Period, Year, Month, Is Reimbursement |
| Usage Details (Child Table) | je Zeile ein Ladevorgang: Gridware Usage, Zeiten, kWh, Preise, Contract Type, Item Code, Gridware Usage ID, Usage Medium Label |
| Totals | kWh, Dauer, Anzahl Sessions und Ladepunkte, Preise excl./incl. VAT |
| Price Details | Fix, Energie, Zeit, Parken getrennt |
| Rechnungsbezug | Link zur Sales Invoice, Status |
8.7 Status
Während seiner Verarbeitung kann ein Customer Usage Data Datensatz verschiedene Status durchlaufen.
Beispielsweise:
Draft
↓
Ready for Billing
↓
Invoiced
↓
Paid8.8 Besonderheiten
- USAGE_ADHOC wird bei der Aggregation übersprungen.
- Hubject: Verbräuche → Kunde = Wert aus Default Hubject Roaming Customer (#289, #290).
- Dienstwagen: Haken Is Reimbursement, ein CUD je Arbeitgeber.
- Betreibergebühren (Ladepunktliste): Monatliche Gebühren aus Gridware-Ladepunkt-CSV, keine API. Logik (#161):
any_paid_active→ Paid;only_internal_active→ Internal; Paid schlägt Internal;mobilithek_synczusätzlich zu Paid. Prozess ist Backlog, fachlich aber Kundenabrechnung. - Historischer Subscription-/CSV-Prozess: siehe vorheriges Kapitel; solange nicht alles auf CUD umgestellt ist, weiter relevant (#2, #32, #63).
8.9 Zusammenfassung
Customer Usage Data bildet die erste kaufmännische Verarbeitungsebene innerhalb der ERPNext-Lösung.
Während Gridware Usage einzelne technische Ladevorgänge beschreibt, fasst Customer Usage Data sämtliche abrechnungsrelevanten Nutzungen eines Kunden zusammen und bereitet diese für die spätere Rechnungsstellung vor.