Kapitel 2 – Fachliche Grundlagen und Systemarchitektur
Ziel dieses Kapitels
Dieses Kapitel vermittelt die grundlegenden Fachbegriffefachlichen Konzepte der ERPNext-Implementierung bei becharged. Es erläutert die beteiligten Parteien, die unterschiedlichen Geschäftsmodelle sowie die wichtigsten Datenobjekte und Zusammenhängederen desZusammenhänge.
Nach dem Lesen dieses Kapitels solltesoll jederein neueneuer Mitarbeiter dieverstehen:
DieDieses beschriebenenVerständnis Begriffe bildenbildet die Grundlage für alle weiteren Kapitel dieser Dokumentation.
2.1 Glossar
Beteiligte API (Application Programming Interface)
Eine API ermöglicht den automatischen Datenaustausch zwischen Gridware und ERPNext. Sämtliche Stammdaten, Vertragsinformationen sowie Verbrauchsdaten werden über definierte REST-Schnittstellen synchronisiert.
Billing Period
Parteien
Die Billingbecharged-Plattform Periodverbindet definiertunterschiedliche denTeilnehmer Abrechnungszeitraum,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:
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:
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 denderen VerbrauchsdatenNutzung gesammelteine undVergütung.
Im ERP-System wird der Betreiber als Supplier geführt.
Lieferant
Lieferanten stellen Leistungen bereit, welche später gegenüber becharged abgerechnet werden.
Beispiele:Dies betrifft insbesondere Betreiber der Ladeinfrastruktur, kann jedoch zukünftig auch weitere Dienstleister umfassen.
becharged
Diebecharged Billing Period dient als gemeinsame Grundlage für Customer Usage Data, Supplier Usage Data sowieübernimmt die spätereRolle Rechnungsstellung.des Plattformbetreibers.
Das Unternehmen koordiniert sämtliche kaufmännischen Prozesse zwischen Kunden, Betreibern und weiteren Vertragspartnern.
Gridware
Gridware istverwaltet dassämtliche führendetechnischen System für die technische Verwaltung der Ladeinfrastruktur.Informationen.
GridwareDazu verwaltet unter anderem:gehören:
ERPNextGridware übernimmtstellt diese Informationen über verschiedeneREST-Schnittstellen APIs.für ERPNext bereit.
ERPNext
ERPNext istbildet dassämtliche führendekaufmännischen kaufmännischeProzesse System.der Plattform ab.
Hier erfolgenentstehen unter anderem:
StammdatenverwaltungKundenRechnungsstellungLieferantenLieferantenabrechnungRechnungenZahlungsverwaltungLieferantenabrechnungenSEPAZahlungenMahnwesen
Gridware Party
Eine Gridware Party repräsentiert einen Vertragspartner innerhalb von Gridware.
Je nach Anwendungsfall handelt es sich dabei um:
Während der Synchronisation wird die Gridware Party automatisch einem Customer oder Supplier in ERPNext zugeordnet.
Gridware Contract
Der Gridware Contract bildet den zentralen Vertrag zwischen den beteiligten Parteien.
Er enthält unter anderem:
Alle späteren Abrechnungsprozesse basieren auf diesem Vertrag.
Gridware Usage
Gridware Usage beschreibt einen einzelnen Ladevorgang bzw. eine abrechnungsrelevante Nutzung.
Jeder Datensatz enthält beispielsweise:
Diese Daten bilden die Grundlage für sämtliche Abrechnungen.
Customer Usage Data
Customer Usage Data stellt die aggregierte Abrechnungseinheit eines Kunden innerhalb einer Billing Period dar.
Mehrere einzelne Gridware Usages werden zu einem Customer Usage Data zusammengefasst.
Das Customer Usage Data dient als Grundlage für die Erstellung einer Sales Invoice.
Supplier Usage Data
Supplier Usage Data bildet die entsprechende Aggregation für Lieferanten.
Es dient als Grundlage für die Erstellung einer Gutschrift per Purchase Invoice.
Sales InvoiceBank
Die SalesBank Invoice istverarbeitet die Kundenrechnung.SEPA-Lastschriften und Zahlungseingänge.
Purchase InvoiceDATEV
DieDATEV Purchaseübernimmt Invoicedie dientFinanzbuchhaltung auf Basis der Lieferantenabrechnung.
SEPA Mandate
Ein SEPA Mandate berechtigt becharged zum Einzug der offenen Forderungen per Lastschrift.
Die Mandate werden über Gridware synchronisiert und inaus ERPNext verwaltet.
Payment Entry
Payment Entries dokumentieren Zahlungsein- und -ausgänge innerhalb von ERPNext.
Contract Type
Der Contract Type beschreibt das Geschäftsmodell eines Vertrages.
Der Contract Type steuert maßgeblich die spätere Abrechnungslogik.
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.
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
Ziel des Datenmodells
Das nachfolgende Entity Relationship Modell beschreibtzeigt die wichtigsten GeschäftsobjekteDatenobjekte desder SystemsERPNext-Lösung sowie deren Beziehungen untereinander.
EsDas Modell dient als Grundlagetechnische fürReferenz und erleichtert das Verständnis sämtlicherder später beschriebenen Geschäftsprozesse.
2.7 Standard ERPNext vs. projektspezifische Erweiterungen
DasIm vollständigeRahmen ER-Modell:der Implementierung wurden zahlreiche Standardfunktionen von ERPNext erweitert oder vollständig neu entwickelt.
Die folgende Übersicht dient als Orientierung für Consultants und Entwickler.
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