Skip to main content

WIP 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.2 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.3 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.4 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

Die Aggregation sorgt dafür, dass sämtliche zusammengehörenden Nutzungen gemeinsam fakturiert werden.

8.5 Aufbau des Customer Usage Data Doctypes

(Dieses Kapitel wird anhand des Doctypes detailliert beschrieben.)

Hier würde – genau wie bei Party, Contract und Usage – jeder Abschnitt des Doctypes erläutert werden.

Beispielsweise:

  • Header
  • Customer
  • Billing Period
  • Contract Type
  • Status
  • Child Table mit Gridware Usages
  • Summen
  • Rechnungsbezug
  • weitere kaufmännische Informationen

8.6 Status

Während seiner Verarbeitung kann ein Customer Usage Data Datensatz verschiedene Status durchlaufen.

Beispielsweise:

Draft

↓

Ready for Billing

↓

Invoiced

↓

Paid


(Die tatsächlichen Status ergänzen wir anhand eures Doctypes.)

8.7 Rechnungsstellung

Aus einem Customer Usage Data Datensatz wird anschließend eine Sales Invoice erzeugt.

Dabei werden:

  • die einzelnen Gridware Usages übernommen,
  • die Summen berechnet,
  • die Verbrauchsdaten für den Rechnungsanhang vorbereitet,
  • und die spätere Zahlungsabwicklung angestoßen.

Customer Usage Data bildet somit den unmittelbaren Ausgangspunkt der Kundenabrechnung.

8.8 Besonderheiten

Hier würde ich alle Sonderfälle dokumentieren.

Zum Beispiel:

  • Dienstwagen
  • Hubject
  • Ad-hoc
  • Reimbursement
  • mehrere Verträge
  • mehrere Companies
  • Rundungslogik
  • Preisregeln

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.