Kapitel 2 – Fachliche Grundlagen und Systemarchitektur

Ziel dieses Kapitels

Dieses Kapitel vermittelt die grundlegenden fachlichen Konzepte der ERPNext-Implementierung bei becharged. Es erläutert die beteiligten Parteien, die unterschiedlichen Geschäftsmodelle sowie die wichtigsten Datenobjekte und deren Zusammenhänge.

2.1 Beteiligte Parteien und Rollen

Die becharged-Plattform verbindet unterschiedliche Teilnehmer miteinander und automatisiert die kaufmännischen Prozesse zwischen ihnen. Je nach Geschäftsmodell übernimmt eine Partei unterschiedliche Rollen innerhalb des Systems. Eine Person oder Organisation aus Gridware kann Kunde und Lieferant sein.

Parteien:

Personen

Personen können als Vertragspartner in der Rolle des Kunden und/oder des Lieferanten auftreten. Gleichzeitig können sie auch lediglich Nutzer sein.

Typische Anwendungsbeispiele:

Private E-Auto Nutzung
Wallbox installiert
Mitarbeiter eines Unternehmens

Unternehmen

Unternehmen treten häufig als Vertragspartner in mehreren Rollen auf und verwalten mehrere Nutzer, Fahrzeuge oder Standorte.

Typische Beispiele sind:

Firmenflotten
Wohnungsbaugesellschaften
Gewerbestandorte
Immobilienverwaltungen

Ein Unternehmen kann mehrere Verträge sowie mehrere Ansprechpartner besitzen.

Rollen:

Lieferant/Betreiber (Charge Point Operator – CPO)

Lieferanten stellen Leistungen bereit, welche später gegenüber becharged abgerechnet werden. Der Betreiber stellt die Ladeinfrastruktur bereit und erhält für deren Nutzung eine Vergütung. Dies betrifft insbesondere Betreiber der Ladeinfrastruktur, kann jedoch zukünftig auch weitere Dienstleister umfassen. In ERP Next wird der Lieferant als Supplier geführt.

Endkunde/User

Der Endkunde nutzt die Ladeinfrastruktur und verursacht durch seine Ladevorgänge abrechnungsrelevante Transaktionen. Je nach Vertragsmodell erhält der Endkunde die Rechnung direkt oder die Abrechnung erfolgt über ein Unternehmen. Innerhalb ERPNext wird der Endkunde als Customer geführt.

becharged

becharged übernimmt die Rolle des Plattformbetreibers. Das Unternehmen koordiniert sämtliche kaufmännischen Prozesse zwischen Kunden, Betreibern und weiteren Vertragspartnern.

Gridware

Gridware verwaltet sämtliche technischen Informationen.

Dazu gehören:

Personen
Organisationen
Verträge
Ladepunkte
Ladevorgänge
Zahlungsmethoden
SEPA-Mandate

Gridware stellt diese Informationen über REST-Schnittstellen für ERPNext bereit.

2.2 Vertragsarten (Contract Types)

Die Vertragsart definiert den fachlichen Ablauf der späteren Abrechnung.

Je nach Contract Type unterscheiden sich:

Rechnungslogik
beteiligte Parteien
Lieferantenabrechnung
Steuersätze
Artikel
Druckformate

USAGE_POSTPAID

Beschreibung

Der Standardvertrag für klassische End-Kundenabrechnungen. Hier wird häufig die Zahlungsart "SEPA-Lastschrift" für die Kunden verwendet.

COMPANY CAR

Beschreibung

Bei Firmenfahrzeugen ist der Rechnungsempfänger das Unternehmen, der Lieferant ist immer der Mitarbeiter, weil er/sie die Wallbox Zuhause installiert hat. Es handelt sich hier um einen Erstattungsprozess mit durchlaufendem Posten.

USAGE_HUBJECT_CPO_ROAMING

Beschreibung

Roaming-Verträge für externe Ladeverbünde. Da teilweise kein direkter Endkunde existiert und dieser vom Drittanbieter abgerechnet werden, wird ein definierter Standardkunde (Grid & Co.) für die Abrechnung von becharged verwendet.

USAGE_ADHOC

Beschreibung

Spontane, öffentliche Ladevorgänge ohne klassischen Vertragsprozess.

Diese Vorgänge werden nicht über die normale Rechnungslogik verarbeitet, sondern direkt über Gridware.

Besonderheiten

keine Customer Usage Rechnung
direkte Zahlungsabwicklung über Payter, PayPal
keine Subscription

2.3 Glossar

Billing Period

Abrechnungszeitraum, in dem sämtliche Ladevorgänge gesammelt werden.

Gridware Party

Vertragspartner innerhalb Gridware.

Kann eine Organisation oder natürliche Person sein.

Gridware Contract

Vertrag zwischen mehreren Parteien.

Bildet die Grundlage sämtlicher Abrechnungsprozesse.

Gridware Usage

Ein einzelner Ladevorgang.

Customer Usage Data

Aggregierte Abrechnungseinheit eines Kunden innerhalb einer Billing Period.

Grundlage für die Sales Invoice.

Customer Usage Detail

Einzelne Ladevorgänge innerhalb eines Customer Usage Data.

Supplier Usage Data

Aggregierte Abrechnungseinheit eines Lieferanten.

Grundlage für die Purchase Invoice.

Supplier Usage Detail

Einzelne Ladevorgänge innerhalb eines Supplier Usage Data.

Payment Entry

Verarbeitung von Zahlungsein- und -ausgängen.

Contract Type

Definiert das zugrunde liegende Geschäftsmodell eines Vertrags.

Subscription

ERPNext-Objekt zur automatischen Fakturierung wiederkehrender Gebühren.

CPO (Charge Point Operator)

Betreiber einer Ladeinfrastruktur.

EMP (E-Mobility Provider)

Anbieter von Ladediensten gegenüber Endkunden.

Reimbursement (Dienstwagen)

Erstattungsmodell, beispielsweise für Dienstwagen oder spezielle Vertragskonstellationen.

2.4 Kernobjekte der ERPNext-Lösung

Die wichtigsten Datenobjekte der ERPNext-Implementierung sind:

Objekt	Zweck
Customer	Rechnungsempfänger
Supplier	Betreiber / Lieferant
Gridware Party	Vertragspartner aus Gridware
Gridware Contract	Vertragsabbild innerhalb ERPNext
Gridware Usage	Einzelner Ladevorgang
Billing Period	Abrechnungszeitraum
Customer Usage Data	Kundenaggregation
Supplier Usage Data	Lieferantenaggregation
Sales Invoice	Kundenrechnung
Purchase Invoice	Lieferantenabrechnung
Payment Entry	Zahlungsverbuchung

Diese Objekte bilden die Grundlage sämtlicher Geschäftsprozesse innerhalb der Plattform.

Kleines Beispiel:

Die Firma Müller GmbH hat einen Vertragslade-Vertrag. Mitarbeiterin Anna lädt im März dreimal an einem becharged-Punkt.

Gridware Party = Müller GmbH (Organisation) und Anna (Person, Is Employee).

Gridware Contract = der Vertrag. Er sagt: Vertragstyp USAGE_POSTPAID, Kunde Müller, Lieferant der CPO, MwSt. 19 %.

Gridware Usage = Annas drei Ladevorgänge (Start, Ende, kWh, Energie-/Park-/Fixkosten).

Customer Usage Data = ein Monatsdatensatz „Müller, 03/2026“ mit allen drei Vorgängen.

Daraus entsteht die Sales Invoice an Müller, Druckformat BCH Rechnung plus Verbrauchsanhang.

Ist Anna Dienstwagenfahrerin, ist der Arbeitgeber der Kunde (eine CUD, eine Rechnung) und Anna der Lieferant (eigene SUD, eigene Gutschrift) (#312).

2.5 Source of Truth

Für jedes Datenobjekt existiert genau ein führendes System.

Datenobjekt	Führendes System
Personen	Gridware
Organisationen	Gridware
Verträge	Gridware
Ladepunkte	Gridware
Ladevorgänge	Gridware
Zahlungsmethoden	Gridware
Customer	ERPNext
Supplier	ERPNext
Sales Invoice	ERPNext
Purchase Invoice	ERPNext
Payment Entry	ERPNext
DATEV Export	ERPNext

Grundsätzlich gilt:

Technische Daten werden in Gridware gepflegt. Kaufmännische Prozesse werden ausschließlich in ERPNext verarbeitet.

2.6 Entity Relationship Modell

Das nachfolgende Entity Relationship Modell zeigt die wichtigsten Datenobjekte der ERPNext-Lösung sowie deren Beziehungen untereinander.

Das Modell dient als technische Referenz und erleichtert das Verständnis der später beschriebenen Geschäftsprozesse.

2.7 Standard ERPNext vs. projektspezifische Erweiterungen

Im Rahmen der Implementierung wurden zahlreiche Standardfunktionen von ERPNext erweitert oder vollständig neu entwickelt.

Die folgende Übersicht dient als Orientierung für Consultants und Entwickler.

Funktion	ERPNext Standard	Individuelle Entwicklung
Customer	✓
Supplier	✓
Sales Invoice	✓	erweitert
Purchase Invoice	✓	erweitert
Subscription	✓	erweitert
Payment Entry	✓
Gridware Party		✓
Gridware Contract		✓
Gridware Usage		✓
Customer Usage Data		✓
Supplier Usage Data		✓
Customer Usage Detail		✓
Supplier Usage Detail		✓
Gridware API Integration		✓
Contract Type Mapping		✓
Customer Portal		✓
SEPA-Integration	✓	erweitert
E-Rechnung	✓ (App)	projektspezifisch konfiguriert