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.

Nach dem Lesen dieses Kapitels soll ein neuer Mitarbeiter verstehen:

welche Parteien innerhalb der Plattform miteinander interagieren, welche Geschäftsmodelle und Vertragsarten unterstützt werden, welche zentralen Datenobjekte innerhalb ERPNext verwendet werden, wie diese Objekte miteinander in Beziehung stehen.

Dieses Verständnis bildet die Grundlage für alle weiteren Kapitel dieser Dokumentation.

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.

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

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.

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.

 

Im ERP-System wird der Betreiber als Supplier geführt.

Lieferant

Lieferanten stellen Leistungen bereit, welche später gegenüber becharged abgerechnet werden.

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.

ERPNext

ERPNext bildet sämtliche kaufmännischen Prozesse der Plattform ab.

Hier entstehen unter anderem:

Kunden Lieferanten Rechnungen Lieferantenabrechnungen Zahlungen Finanzexporte

Bank

Die Bank verarbeitet die SEPA-Lastschriften und Zahlungseingänge.

DATEV

DATEV übernimmt die Finanzbuchhaltung auf Basis der aus ERPNext exportierten Buchungsdaten.

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:

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.

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.