Kapitel 7 – Verarbeitung von Ladevorgängen
Ziel dieses Kapitels
Nachdem Stammdaten und Vertragsinformationen erfolgreich aus Gridware nach ERPNext synchronisiert wurden, bildet die Verarbeitung der Ladevorgänge den nächsten zentralen Schritt innerhalb der ERPNext-Lösung.
Jeder einzelne Ladevorgang repräsentiert die Nutzung eines Ladepunkts und bildet die kleinste abrechnungsrelevante Einheit des Systems. Erst durch die anschließende Aggregation mehrerer Ladevorgänge innerhalb eines Abrechnungszeitraums entstehen kaufmännische Belege wie Kunden- oder Lieferantenabrechnungen.
Dieses Kapitel beschreibt den Aufbau des Gridware Usage Doctypes sowie dessen Rolle innerhalb des gesamten Abrechnungsprozesses.
7.1 Fachlicher Hintergrund
Ein Gridware Usage repräsentiert einen einzelnen Ladevorgang und bildet die kleinste abrechnungsrelevante Einheit innerhalb des Systems. Jeder Ladevorgang entsteht ausschließlich in Gridware und wird anschließend vollständig nach ERPNext synchronisiert. Der Gridware Usage stellt dabei das technische und fachliche Abbild eines einzelnen Ladevorgangs dar.
Im Gegensatz zu vielen Integrationen werden die Daten nicht innerhalb von ERPNext berechnet oder nachträglich angereichert. Bereits beim Abruf aus Gridware enthält der Datensatz sämtliche relevanten Informationen, die für die spätere kaufmännische Verarbeitung benötigt werden.
Hierzu gehören unter anderem:
-
die zugehörigen Vertragsinformationen,
-
der Contract Type,
-
der zahlende Kunde,
-
der beteiligte Lieferant,
-
sämtliche Preisinformationen,
-
die Verbrauchswerte,
-
sowie weitere technische und kaufmännische Informationen.
ERPNext übernimmt diese Informationen unverändert und verwendet sie als Grundlage für die spätere Aggregation und Rechnungsstellung.
Der Gridware Usage bildet damit die Basis für:
-
Customer Usage Data
-
Supplier Usage Data
-
Kundenabrechnungen
-
Lieferantenabrechnungen
-
Auswertungen und Reports
7.2 Architekturprinzip
Der Gridware Usage wurde bewusst als Spiegelbild der Gridware-Daten entwickelt. Das bedeutet, dass ERPNext keine fachlichen Informationen wie Preise, Vertragszuordnungen oder beteiligte Parteien selbst berechnet. Stattdessen werden diese Informationen bereits vollständig von Gridware bereitgestellt und unverändert übernommen.
7.3 Lebenszyklus eines Ladevorgangs
Die Verarbeitung eines Ladevorgangs erfolgt in mehreren Schritten.
Gridware
↓
Gridware Usage
↓
Customer Usage Data
↓
Supplier Usage Data
↓
Sales Invoice / Purchase Invoice
Nachdem der Ladevorgang aus Gridware synchronisiert wurde, wird er den entsprechenden Kunden- und Lieferantenaggregationen zugeordnet. Erst diese Aggregationen bilden die Grundlage für die spätere Rechnungsstellung.
Es gibt in den Settings keine Schaltfläche „alle Usages neu holen“. Usages kommen mit den Verträgen. Nachziehen geht über Abruf fehlgeschlagener/ausstehender Transaktionen wiederholen.
Nur Transaktionen mit Status DONE oder DONE_WITH_TERMINATION werden verarbeitet.
7.4 Aufbau des Gridware Usage Doctypes
Der Gridware Usage Doctype gliedert sich in mehrere logisch getrennte Bereiche. Gemeinsam bilden sie sämtliche technischen und kaufmännischen Informationen eines einzelnen Ladevorgangs ab.
Usage Information
Dieser Bereich enthält die grundlegenden Informationen zum Ladevorgang. Gespeichert werden unter anderem:
| Feld | Datentyp | Quelle | Beschreibung |
|---|---|---|---|
gridware_usage_id |
Int (unique) | Gridware API | Externe Identifikator |
uuid |
Text | Gridware API | Eindeutige UUID |
status |
Select | Intern | Pending / Complete / Failed |
receipt_number |
Text | Gridware API | Quittungsnummer |
start |
Datetime | Gridware API | Ladestart |
end |
Datetime | Gridware API | Ladeende |
duration |
Int | Gridware API | Dauer in Sekunden |
state |
Text | Gridware API | Zustand aus Gridware |
Die Gridware Usage ID dient als eindeutiger technischer Identifikator zwischen Gridware und ERPNext.
- Pending bedeutet: Details fehlen noch.
- Complete ist die Voraussetzung für die Aggregation.
- Failed muss nachgezogen werden.
Der Status wird direkt aus Gridware übernommen und beschreibt den aktuellen Bearbeitungszustand des Ladevorgangs.
Consumption Information
Dieser Bereich beschreibt den tatsächlichen Energieverbrauch. API liefert Wh, ERPNext zeigt zusätzlich kWh (geteilt durch 1000)
Hier werden unter anderem gespeichert:
| Feld | Datentyp | Transformation | Beschreibung |
|---|---|---|---|
consumption_start_in_wh |
Float | API → DB | Zählerstand Start (Wh) |
consumption_end_in_wh |
Float | API → DB | Zählerstand Ende (Wh) |
consumption_value_in_wh |
Float | API → DB | Verbrauch in Wh |
consumption_start_in_kwh |
Float | Wh ÷ 1000 | Zählerstand Start (kWh) |
consumption_end_in_kwh |
Float | Wh ÷ 1000 | Zählerstand Ende (kWh) |
consumption_value_in_kwh |
Float | Wh ÷ 1000 | Verbrauch in kWh |
rental_object_id |
Text | Gridware API | Ladesäulen-ID |
rental_object_display_name |
Text | Gridware API |
Ladesäulen-Name |
Diese Informationen dienen später als Grundlage für die Verbrauchsauswertung und Rechnungsstellung.
Usage Price Details
Im Bereich Usage Price Details werden sämtliche von Gridware berechneten Kosten übernommen.
Je nach Vertragsmodell können folgende Kostenarten vorhanden sein:
Struktur: Netto + Brutto für jede Kostenart
| Kostenart | Netto Feld | Brutto Feld |
|---|---|---|
| Fix | usage_price_total_fix_costs_excl_vat |
usage_price_total_fix_costs_incl_vat |
| Energy | usage_price_total_energy_costs_excl_vat |
usage_price_total_energy_costs_incl_vat |
| Time | usage_price_total_time_costs_excl_vat |
usage_price_total_time_costs_incl_vat |
| Parking | usage_price_total_parking_costs_excl_vat |
usage_price_total_parking_costs_incl_vat |
| Reservation | usage_price_total_reservation_costs_excl_vat |
usage_price_total_reservation_costs_incl_vat |
Sowohl Netto- als auch Bruttopreise werden gespeichert. Preise kommen aus der API in Cent und werden in Euro mit zwei Dezimalstellen gespeichert.
ERPNext übernimmt diese Werte unverändert. Eine erneute Preisberechnung innerhalb ERPNext erfolgt nicht.
User Information
Dieser Bereich beschreibt den Nutzer des Ladevorgangs.
Hierzu gehören unter anderem:
| Feld | Datentyp | Quelle | Beschreibung |
|---|---|---|---|
user_usage_medium_subject_type |
Text | Gridware API | Subject Type (Person/Org) |
user_usage_medium_label |
Text | Gridware API | Nutzer-Identifikator (NFC) |
user_name |
Text | Gridware API | Zahlender Kunde (Name) |
user_person_id |
Int | Gridware API | Person ID |
gridware_party_person |
Link | Query | Verknüpfung → Gridware Party (Person) |
user_organization_id |
Int | Gridware API | Organization ID |
gridware_party_organization |
Link | Query | Verknüpfung → Gridware Party (Org) |
user_references |
JSON | Gridware API | Weitere Referenzen |
Dadurch kann jeder Ladevorgang eindeutig einer Person oder Organisation zugeordnet werden.
Über die Gridware Party erfolgt die Verknüpfung mit den kaufmännischen Stammdaten innerhalb ERPNext.
Authorizing Contracts
Dieser Bereich stellt die Verbindung zwischen dem Ladevorgang und dem zugrunde liegenden Vertrag her.
Gespeichert werden unter anderem:
| Feld | Datentyp | Beschreibung |
|---|---|---|
gridware_authorizing_contract_id |
Text | Contract ID aus API |
cpo_offer_id |
Text | CPO Offer ID |
contract_type |
Text | Vertragstyp |
contract_simple_name |
Text | Kurzbeschreibung |
contract_number |
Text | Vertragsnummer |
Dadurch erhält jeder Ladevorgang sämtliche Informationen, die für die spätere kaufmännische Verarbeitung erforderlich sind.
Der Vertrag bestimmt unter anderem:
-
welches Vertragsmodell gilt,
-
welcher Lieferant beteiligt ist,
-
welche Kunden berücksichtigt werden,
-
welche Billing Rules angewendet werden.
Payment Information
Im letzten Abschnitt werden die Zahlungsinformationen gespeichert.
Aktuell wird insbesondere die Payment Method Reference ID übernommen.
| Feld | Datentyp | Beschreibung |
|---|---|---|
payment_method_ref_id |
Int | Payment Method ID |
payment_method_ref_identifier |
Text | Payment Method Name |
payment_method_ref_type |
Text | Typ (SEPA, CARD, etc.) |
payment_method_ref_card_type |
Text | Kartentyp (bei CARD) |
Dieser Bereich bildet die Grundlage für zukünftige Erweiterungen der Zahlungsabwicklung und dient der eindeutigen Zuordnung der verwendeten Zahlungsmethode.
7.5 Verwendung innerhalb der ERPNext-Lösung
Der Gridware Usage dient ausschließlich als technische Datengrundlage. Er wird selbst nicht direkt fakturiert. Stattdessen bildet er die Grundlage für die weitere kaufmännische Verarbeitung.
Mehrere Gridware Usages werden innerhalb einer Billing Period zusammengefasst und anschließend zu folgenden Objekten aggregiert:
-
Customer Usage Data
-
Supplier Usage Data
Diese Aggregationen bilden wiederum die Grundlage für die Erstellung von Kunden- und Lieferantenrechnungen.
7.6 Abgrenzung zu Customer Usage Data und Supplier Usage Data
Es ist wichtig, zwischen dem Gridware Usage und den späteren Aggregationsobjekten zu unterscheiden.
| Gridware Usage | Customer / Supplier Usage Data |
|---|---|
| Einzelner Ladevorgang | Zusammenfassung mehrerer Ladevorgänge |
| Technisches Abbild aus Gridware | Kaufmännische Aggregation innerhalb ERPNext |
| Wird direkt aus Gridware übernommen | Wird innerhalb ERPNext erzeugt |
| Keine Rechnungsstellung | Grundlage für die Rechnungsstellung |
Während der Gridware Usage den unveränderten Ursprung eines Ladevorgangs darstellt, enthalten Customer Usage Data und Supplier Usage Data die kaufmännisch aufbereiteten Daten für die spätere Abrechnung.
7.7 Zusammenfassung
Der Gridware Usage bildet die technische Grundlage der gesamten Abrechnungslösung.
Jeder Ladevorgang wird vollständig aus Gridware übernommen und unverändert innerhalb ERPNext gespeichert. Dadurch bleibt Gridware das führende System für sämtliche Nutzungsdaten, während ERPNext die Rolle des kaufmännischen Verarbeitungssystems übernimmt.
Die eigentliche Geschäftslogik beginnt erst im nächsten Schritt mit der Aggregation mehrerer Gridware Usages zu Customer Usage Data und Supplier Usage Data, welche die Basis für die spätere Rechnungsstellung bilden.