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.