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.2 Schritt für Schritt 

Vorraussetzungen: Alle Stammdaten sind geladen und verknüpft. Der Vertrag, Lieferanten und Kunden, sowie Transaktionen sind geladen per API. In den Einstellungen müssen die korrekten Artikel auf den Vertrag gemapped sein. 

    Öffne die becharged Settings.  Klicke auf den Button "Customer Usage Data"  Wähle den jeweiligen Kunden aus + wenn gewollt wähle den Abrechnungszeitraum  Customer Usage Data mit aggregierten Transaktionen wird erstellt für jeweiligen Kunden  Öffne den DocType "Customer Usage Data", wähle das jeweilge Dokument  Klicke auf den Button "Create Sales Invoice"  Eine Rechnung mit dem Gesamtbetrag und dem korrekten Betrag wird erstellt.  Im Druckformat findest du die Rechnung mit Anhang. 

    Customer Usage Data.gif

    Dienstwagen-Fall: 

    Lieferanten bekommen Dienstwagen-Rechnungen - teilweise von mehreren Mitarbeitenden. Diese sollen alle für den Abrechnungszeitraum gebündelt und in einer Rechnung abgebildet werden. Im Druckformat ist klar erkennbar, welche Transaktionen zu welchem Mitarbeitenden gehören. Alle Transaktionen sind zu einem Rechnungsbetrag zusammengefasst.

    Custmer Usage Data - reimbursement .gif

    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 (DiesesChild KapitelTable) wirdje anhandZeile desein DoctypesLadevorgang: detailliertGridware beschrieben.)Usage,

    HierZeiten, würdekWh, –Preise, genauContract wieType, beiItem Party,Code, ContractGridware Usage ID, Usage Medium Label

    Totals kWh, Dauer, Anzahl Sessions und UsageLadepunkte, –Preise jederexcl./incl. AbschnittVAT des DoctypeserläutertPrice werden.Details

    Beispielsweise:

    Fix,
      Energie, HeaderZeit, CustomerParken Billinggetrennt Period Contract TypeRechnungsbezug Link zur Sales Invoice, Status Child Table mit Gridware Usages Summen Rechnungsbezug weitere kaufmännische Informationen

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

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

      Dabei werden:Besonderheiten

      • dieUSAGE_ADHOC einzelnenwird Gridwarebei Usagesder übernommen,Aggregation übersprungen.
      • dieHubject: SummenVerbräuche berechnet,→ Kunde = Wert aus Default Hubject Roaming Customer (#289, #290).
      • dieDienstwagen: VerbrauchsdatenHaken fürIs denReimbursement, Rechnungsanhangein vorbereitet,CUD je Arbeitgeber.
      • undBetreibergebühren die(Ladepunktliste): spätereMonatliche ZahlungsabwicklungGebühren angestoßen.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).

      Customer Usage Data bildet somit den unmittelbaren Ausgangspunkt der Kundenabrechnung.

      8.9 Besonderheiten

      Hier würde ich alle Sonderfälle dokumentieren.

      Zum Beispiel:

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