Skip to main content

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 Entry

8.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

↓

Paid

8.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_sync zusä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.

No comments to display