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.