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
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.
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 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.
Betreiber (Charge Point Operator – CPO)
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.
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:
| 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.
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 |