# Prozesszeichnungen

# Datenstruktur Gridware mit ERP Next - ER Modell + Use Cases

<div drawio-diagram="121"><img src="https://becharged.phamos.eu/uploads/images/drawio/2026-02/drawing-11-1771238007.png" alt="drawing-11-1771238007.png"/></div>

### **RULES:** 

Wer erhält Rechnung: Contractor = Customer (Organisation oder Individuum) /Vertragskunde oder Ad-Hoc-Endkunde  
Wer bekommt eine Gutschrift/Auszahlung? = Supplier (CPO) oder Customer (bei Dienstwagen)   
Wer nutzt nur? = End User (muss oft nur für Zuordnung/Reporting existieren)

### **Geldströme:** 

A) Einnahmen (Money-In)

1. Endkunde / Vertragspartner zahlt für Ladevorgänge 
    - via Invoice/SEPA, oder Direct Payment (Payter/Stripe/PayPal), oder Pay-as-you-go
2. Contract Giver zahlt für Ladepunkte/Service (Miete/Betrieb/Backend/Hardware)

B) Ausgaben (Money-Out)

1. becharged zahlt Gutschrift an den Contract Giver 
    - typischerweise “Energieumsatz / Standortanteil” (Pass-through)
2. Optional: becharged zahlt Erstattungen

C) Marge

becharged verdient in der Regel nicht am “reinen Durchlauf” (Energie), sondern an:

- Service-/Plattformgebühren: M100035: Kosten Betriebsführung 10%
- Abonnement-Zahlungen: Charge &amp; Share
- Hardware Ladepunkt-Gebühren: Bspw. M100213: Betriebsführung von Ladeeinrichtungen

<p class="callout warning">**Wichtig für ERP:** sauber trennen  
- Pass-through (durchlaufender Posten → Auszahlung später)  
- Eigener Umsatz (Fee)</p>

### **USE CASES :**

**USE CASE 1: Laden im Unternehmen/beim Mandanten (Mitarbeiter/Vertragskunde) - Contract "Usage Contract (billable)"**

BEISPIEL Unternehmen: [https://cloud.becharged.de/backoffice/contracts/251](https://cloud.becharged.de/backoffice/contracts/251)   
BEISPIEL Kunde:   
BEISPIEL Wohngesellschaft/Vermieter: [https://cloud.becharged.de/backoffice/contracts/306](https://cloud.becharged.de/backoffice/contracts/306)

<div drawio-diagram="109"><img src="https://becharged.phamos.eu/uploads/images/drawio/2026-02/drawing-11-1770797781.png" alt="drawing-11-1770797781.png"/></div>

<div drawio-diagram="139"><img src="https://becharged.phamos.eu/uploads/images/drawio/2026-03/drawing-11-1773221761.png" alt="drawing-11-1773221761.png"/></div>

**USE CASE 2: Laden im Unternehmen/beim Mandanten (Besucher/E-Fahrer) - Public Charging - Contract: "Adhoc usage contract"**

BEISPIEL: [https://cloud.becharged.de/backoffice/contracts/286](https://cloud.becharged.de/backoffice/contracts/286)

<div drawio-diagram="108"><img src="https://becharged.phamos.eu/uploads/images/drawio/2026-02/drawing-11-1770793527.png" alt="drawing-11-1770793527.png"/></div>

**Use Case 3: Laden im Unternehmen/Kunde (Besucher/E-Fahrer) - Roaming über Hubject EMP-Vertrag**  
BEISPIEL: ?

<div drawio-diagram="107"><img src="https://becharged.phamos.eu/uploads/images/drawio/2026-02/drawing-11-1770793425.png" alt="drawing-11-1770793425.png"/></div>

**USE CASE 4: Dienstwagen** BEISPIEL: [https://cloud.becharged.de/backoffice/contracts/484](https://cloud.becharged.de/backoffice/contracts/484)

<div drawio-diagram="106"><img src="https://becharged.phamos.eu/uploads/images/drawio/2026-02/drawing-11-1770793399.png" alt="drawing-11-1770793399.png"/></div>

### **TRANSLATE:** 

**RULES:**

Who receives the invoice: **Contractor = Customer** (organization or individual) / contract customer or ad-hoc end customer  
Who receives a credit note / payout: **Supplier** (CPO) or **Customer** (in the company car use case)  
Who only uses the service: **End User** (often only needs to exist for assignment/reporting)

---

**Money flows:**

**A) Revenue (Money-In)**

- End customer / contract partner pays for charging sessions  
    via invoice/SEPA, or direct payment (Payter/Stripe/PayPal), or pay-as-you-go
- Contract giver pays for charging points/services (rent/operations/backend/hardware)

**B) Expenses (Money-Out)**

- BeCharged pays a credit note to the contract giver  
    typically “energy turnover / site share” (pass-through)
- Optional: BeCharged pays reimbursements

**C) Margin**  
BeCharged typically does **not** earn on the “pure pass-through” (energy), but on:

- Service/platform fees: **M100035: operations management cost 10%**
- Subscription payments: **Charge &amp; Share**
- Hardware/charging point fees: e.g. **M100213: operations management of charging infrastructure**

**Important for ERP: separate clearly**

- Pass-through (clearing account → payout later)
- Own revenue (fee)

---

**USE CASES:**

**USE CASE 1: Charging at the company / at the client (employee / contract customer) — Contract “Usage Contract (billable)”**

Example company: [https://cloud.becharged.de/backoffice/contracts/251<span class="ms-0.5 inline-block align-middle leading-none"></span>](https://cloud.becharged.de/backoffice/contracts/251)  
Example customer:  
Example housing association/landlord: [https://cloud.becharged.de/backoffice/contracts/306](https://cloud.becharged.de/backoffice/contracts/306)

<div drawio-diagram="68"><img src="https://becharged.phamos.eu/uploads/images/drawio/2026-02/drawing-8-1770201371.png" alt="drawing-8-1770201371.png"/></div>

# Datastructure Gridware to ERP Next - ER Modell + Use Cases ENG

**<span style="background-color:rgb(194,224,244);">Old version: </span>**

<div drawio-diagram="148"><img src="https://becharged.phamos.eu/uploads/images/drawio/2026-03/drawing-11-1773694469.png" alt="drawing-11-1773694469.png"/></div>

**<span style="background-color:rgb(230,126,35);">New Version </span>**

<div drawio-diagram="211"><img src="https://becharged.phamos.eu/uploads/images/drawio/2026-06/drawing-11-1782823226.png" alt="drawing-11-1782823226.png"/></div>

<div drawio-diagram="209"><img src="https://becharged.phamos.eu/uploads/images/drawio/2026-06/drawing-11-1782823144.png" alt="drawing-11-1782823144.png"/></div>

#### **RULES:**

Who receives the invoice:  
**Contractor = Customer** (organization or individual) / contractual customer or ad-hoc end customer

Who receives a credit note / payout:  
**Supplier (CPO)** or **Customer** (in the company car use case)

Who only uses the service:  
**End User** (often exists only for assignment/reporting purposes)

#### **MONEY FLOWS:** 

**A) Revenue (Money-In)**

\- End customer / contractual partner pays for charging sessions  
via **Invoice/SEPA**, or **Direct Payment** (Payter / Stripe / PayPal), or **Pay-as-you-go**

\- Contract Giver pays for **charging infrastructure / services**  
(e.g., rent / operations / backend / hardware)

**B) Expenses (Money-Out)**

\- becharged pays a **credit note / payout** to the **Contract Giver**

\- Typically: **energy revenue / location share** (pass-through)

\- Optional: becharged pays **reimbursements**

---

**C) Margin**

becharged typically does **not earn on pure pass-through energy revenue**, but rather on:

**- Service / platform fees**  
Example: *M100035 – Operations management fee 10%*

**- Subscription payments**  
Example: *Charge &amp; Share*

**- Charging hardware operation fees**  
Example: *M100213 – Operation of charging infrastructure*

**Important for ERP: clearly separate**

- **Pass-through amounts** (transitory items → paid out later)
- **Own revenue** (service/platform fees)

### **USE CASES**

#### **USE CASE 1:** Charging at a company / tenant location  
(Employee / contractual customer)

Contract type: **“Usage Contract (billable)”**

example Company: [https://cloud.becharged.de/backoffice/contracts/251](https://cloud.becharged.de/backoffice/contracts/251)   
example Kunde:   
example landlord: [https://cloud.becharged.de/backoffice/contracts/306](https://cloud.becharged.de/backoffice/contracts/306)

<div drawio-diagram="199"><img src="https://becharged.phamos.eu/uploads/images/drawio/2026-06/drawing-11-1782821742.png" alt="drawing-11-1782821742.png"/></div>

**USE CASE 2: Charging at Company/Mandate (Visitors, E-car drivers) - Public Charging - Contract: "Adhoc usage contract"**

Example: [https://cloud.becharged.de/backoffice/contracts/286](https://cloud.becharged.de/backoffice/contracts/286)

<div drawio-diagram="207"><img src="https://becharged.phamos.eu/uploads/images/drawio/2026-06/drawing-11-1782822409.png" alt="drawing-11-1782822409.png"/></div>

**Use Case 3:Charging at Company/Mandate (Besucher/E-Car Driver) - Roaming via Hubject EMP-Contract**  
example: ?

<div drawio-diagram="203"><img src="https://becharged.phamos.eu/uploads/images/drawio/2026-06/drawing-11-1782822005.png" alt="drawing-11-1782822005.png"/></div>

**USE CASE 4: Company Car - Employee receives charging box at his home, charges at home - supplies with electricity, company pays for electricty** Example: [https://cloud.becharged.de/backoffice/contracts/484](https://cloud.becharged.de/backoffice/contracts/484)

<div drawio-diagram="205"><img src="https://becharged.phamos.eu/uploads/images/drawio/2026-06/drawing-11-1782822074.png" alt="drawing-11-1782822074.png"/></div>

# Data Mapping Gridware to ERP Next

## Mapping to Party Master DocType for Master Data 

##### **Organisation** 

<table class="t1" id="bkmrk-gridware-field-api-z" style="width:100%;height:579.719px;"><tbody><tr style="height:46.5938px;"><td class="td1" style="width:22.5958%;height:46.5938px;">**Gridware field**

</td><td class="td1" style="width:16.2993%;height:46.5938px;">API

</td><td class="td1" style="width:10.8175%;height:46.5938px;">**Ziel-Doctype**

</td><td class="td1" style="width:19.4401%;height:46.5938px;">**Ziel-Feld in ERPNext**

</td><td class="td1" style="width:30.7282%;height:46.5938px;">**Bemerkung**

</td></tr><tr style="height:46.5938px;"><td class="td1" style="width:22.5958%;height:46.5938px;">id (Organization ID)

</td><td class="td1" style="width:16.2993%;height:46.5938px;">/services/organizations

</td><td class="td1" style="width:10.8175%;height:46.5938px;">Master Party

</td><td class="td1" style="width:19.4401%;height:46.5938px;">gridware\_organization\_id

</td><td class="td1" style="width:30.7282%;height:46.5938px;">Eindeutige Org-ID

</td></tr><tr style="height:46.5938px;"><td class="td1" style="width:22.5958%;height:46.5938px;">id (Organization ID)

</td><td class="td1" style="width:16.2993%;height:46.5938px;">/services/organizations

</td><td class="td1" style="width:10.8175%;height:46.5938px;">Master Party

</td><td class="td1" style="width:19.4401%;height:46.5938px;">gridware\_subject\_id

</td><td class="td1" style="width:30.7282%;height:46.5938px;">Normalisierte Haupt-ID

</td></tr><tr style="height:46.5938px;"><td class="td1" style="width:22.5958%;height:46.5938px;">“ORGANIZATION" set by API URL

</td><td class="td1" style="width:16.2993%;height:46.5938px;">/services/organizations

</td><td class="td1" style="width:10.8175%;height:46.5938px;">Master Party

</td><td class="td1" style="width:19.4401%;height:46.5938px;">gridware\_subject\_type

</td><td class="td1" style="width:30.7282%;height:46.5938px;">Für einheitliche Importlogik

</td></tr><tr style="height:46.5938px;"><td class="td1" style="width:22.5958%;height:46.5938px;">name

</td><td class="td1" style="width:16.2993%;height:46.5938px;">/services/organizations

</td><td class="td1" style="width:10.8175%;height:46.5938px;">Master Party

</td><td class="td1" style="width:19.4401%;height:46.5938px;">organization\_name

</td><td class="td1" style="width:30.7282%;height:46.5938px;">Official Name

</td></tr><tr style="height:46.5938px;"><td class="td1" style="width:22.5958%;height:46.5938px;">name

</td><td class="td1" style="width:16.2993%;height:46.5938px;">/services/organizations

</td><td class="td1" style="width:10.8175%;height:46.5938px;">Master Party

</td><td class="td1" style="width:19.4401%;height:46.5938px;">display\_name

</td><td class="td1" style="width:30.7282%;height:46.5938px;">Display Name

</td></tr><tr style="height:113.781px;"><td class="td1" style="width:22.5958%;height:113.781px;">type

</td><td class="td1" style="width:16.2993%;height:113.781px;">/services/organizations

</td><td class="td1" style="width:10.8175%;height:113.781px;">Master Party

</td><td class="td1" style="width:19.4401%;height:113.781px;">is\_customer / is\_supplier

</td><td class="td1" style="width:30.7282%;height:113.781px;">CUSTOMER → is\_customer = 1, is\_supplier = 0

SUPPLIER → is\_customer = 0, is\_supplier = 1

BOTH → is\_customer = 1, is\_supplier = 1

</td></tr><tr style="height:46.5938px;"><td class="td1" style="width:22.5958%;height:46.5938px;">customerNumber

</td><td class="td1" style="width:16.2993%;height:46.5938px;">/services/organizations

</td><td class="td1" style="width:10.8175%;height:46.5938px;">Master Party

</td><td class="td1" style="width:19.4401%;height:46.5938px;">gridware\_customer\_number

</td><td class="td1" style="width:30.7282%;height:46.5938px;">Falls vorhanden

</td></tr><tr style="height:46.5938px;"><td class="td1" style="width:22.5958%;height:46.5938px;">supplierNumber

</td><td class="td1" style="width:16.2993%;height:46.5938px;">/services/organizations

</td><td class="td1" style="width:10.8175%;height:46.5938px;">Master Party

</td><td class="td1" style="width:19.4401%;height:46.5938px;">gridware\_supplier\_number

</td><td class="td1" style="width:30.7282%;height:46.5938px;">Falls vorhanden

</td></tr><tr style="height:46.5938px;"><td class="td1" style="width:22.5958%;height:46.5938px;">API Payload

</td><td class="td1" style="width:16.2993%;height:46.5938px;">/services/organizations

</td><td class="td1" style="width:10.8175%;height:46.5938px;">Master Party

</td><td class="td1" style="width:19.4401%;height:46.5938px;">raw\_payload

</td><td class="td1" style="width:30.7282%;height:46.5938px;">Für Debugging/Sync

</td></tr><tr style="height:46.5938px;"><td class="td1" style="width:22.5958%;height:46.5938px;">Import Datetime

</td><td class="td1" style="width:16.2993%;height:46.5938px;">/services/organizations

</td><td class="td1" style="width:10.8175%;height:46.5938px;">Master Party

</td><td class="td1" style="width:19.4401%;height:46.5938px;">last\_imported\_at

</td><td class="td1" style="width:30.7282%;height:46.5938px;">Systemseitig setzen

</td></tr></tbody></table>

##### **Person**:

<table class="t1" id="bkmrk-gridware-feld-api-zi"><tbody><tr><td class="td1">**Gridware Feld**

</td><td class="td1">API

</td><td class="td1">**Ziel-Doctype**

</td><td class="td1">**Ziel-Feld in ERPNext**

</td><td class="td1">**Bemerkung**

</td></tr><tr><td class="td1">ID (Person ID)

</td><td class="td1">/services/persons/export

</td><td class="td1">Master Party

</td><td class="td1">gridware\_person\_id

</td><td class="td1">Eindeutige Personen-ID

</td></tr><tr><td class="td1">ID (Person ID)

</td><td class="td1">/services/persons/export

</td><td class="td1">Master Party

</td><td class="td1">gridware\_subject\_id

</td><td class="td1">Normalisierte Haupt-ID

</td></tr><tr><td class="td1">"PERSON" set by API URL

</td><td class="td1">/services/persons/export

</td><td class="td1">Master Party

</td><td class="td1">gridware\_subject\_type

</td><td class="td1">Für einheitliche Importlogik

</td></tr><tr><td class="td1">Firstname

</td><td class="td1">/services/persons/export

</td><td class="td1">Master Party

</td><td class="td1">first\_name

</td><td class="td1">Vorname

</td></tr><tr><td class="td1">Lastname

</td><td class="td1">/services/persons/export

</td><td class="td1">Master Party

</td><td class="td1">last\_name

</td><td class="td1">Nachname

</td></tr><tr><td class="td1">Firstname + Lastname

</td><td class="td1">/services/persons/export

</td><td class="td1">Master Party

</td><td class="td1">display\_name

</td><td class="td1">Zusammengesetzter Anzeigename

</td></tr><tr><td class="td1">Account.email

</td><td class="td1">/services/persons/export

</td><td class="td1">Master Party

</td><td class="td1">email

</td><td class="td1">Haupt-E-Mail

</td></tr><tr><td class="td1">API Payload komplett

</td><td class="td1">/services/persons/export

</td><td class="td1">Master Party

</td><td class="td1">raw\_payload

</td><td class="td1">Für Debugging/Sync

</td></tr><tr><td class="td1">Import-Zeitpunkt

</td><td class="td1">/services/persons/export

</td><td class="td1">Master Party

</td><td class="td1">last\_imported\_at

</td><td class="td1">Systemseitig setzen

</td></tr></tbody></table>

#####  **Adress for Organisation or Person** 

<table class="t1" id="bkmrk-gridware-feld-api-zi-1"><tbody><tr><td class="td1">**Gridware Feld**

</td><td class="td1">API

</td><td class="td1">**Ziel-Doctype**

</td><td class="td1">**Ziel-Feld in ERPNext**

</td><td class="td1">**Bemerkung**

</td></tr><tr><td class="td1">ID (Address)

</td><td class="td1">/services/addresses/for-organization/{organizationId}/{addressType} OR /services/addresses/for-person/{personId}

</td><td class="td1">Master Party Address

</td><td class="td1">external\_address\_id

</td><td class="td1">Externe Address-ID

</td></tr><tr><td class="td1">Address Type

</td><td class="td1">services/addresses/for-organization/{organizationId}/{addressType} OR /services/addresses/for-person/{personId}

</td><td class="td1">Master Party Address

</td><td class="td1">address\_type

</td><td class="td1">Postal / Billing / Invoice

</td></tr><tr><td class="td1">Street

</td><td class="td1">services/addresses/for-organization/{organizationId}/{addressType} OR /services/addresses/for-person/{personId}

</td><td class="td1">Master Party Address

</td><td class="td1">street

</td><td class="td1">Straße

</td></tr><tr><td class="td1">Streetno

</td><td class="td1">services/addresses/for-organization/{organizationId}/{addressType} OR /services/addresses/for-person/{personId}

</td><td class="td1">Master Party Address

</td><td class="td1">street\_no

</td><td class="td1">Hausnummer

</td></tr><tr><td class="td1">zipCode

</td><td class="td1">services/addresses/for-organization/{organizationId}/{addressType} OR /services/addresses/for-person/{personId}

</td><td class="td1">Master Party Address

</td><td class="td1">zip\_code

</td><td class="td1">PLZ

</td></tr><tr><td class="td1">City

</td><td class="td1">/services/addresses/for-organization/{organizationId}/{services/addresses/for-organization/{organizationId}/{addressType} OR /services/addresses/for-person/{personId}}

</td><td class="td1">Master Party Address

</td><td class="td1">city

</td><td class="td1">Ort

</td></tr><tr><td class="td1">Country

</td><td class="td1">services/addresses/for-organization/{organizationId}/{addressType} OR /services/addresses/for-person/{personId}

</td><td class="td1">Master Party Address

</td><td class="td1">country

</td><td class="td1">Map on ERPNext Country

</td></tr><tr><td class="td1">Telephone

</td><td class="td1">services/addresses/for-organization/{organizationId}/{addressType} OR /services/addresses/for-person/{personId}

</td><td class="td1">Master Party Address

</td><td class="td1">telephone

</td><td class="td1">Telefon

</td></tr><tr><td class="td1">Email

</td><td class="td1">services/addresses/for-organization/{organizationId}/{addressType} OR /services/addresses/for-person/{personId}

</td><td class="td1">Master Party Address

</td><td class="td1">email

</td><td class="td1">Falls auf Address-Level vorhanden

</td></tr><tr><td class="td1">Primary Flag

</td><td class="td1">?

</td><td class="td1">Master Party Address

</td><td class="td1">is\_primary

</td><td class="td1">Falls Gridware so etwas liefert

</td></tr><tr><td class="td1">erzeugter ERPNext Address Datensatz

</td><td class="td1">Link

</td><td class="td1">Master Party Address

</td><td class="td1">erpnext\_address

</td><td class="td1">Optional nachgelagert

</td></tr></tbody></table>

##### **Payment Methode:**

<table class="t1" id="bkmrk-gridware-feld-api-ad"><tbody><tr><td class="td1">**Gridware Feld**

</td><td class="td1">API adress

</td><td class="td1">**Ziel-Doctype**

</td><td class="td1">**Ziel-Feld in ERPNext**

</td><td class="td1">**Bemerkung**

</td></tr><tr><td class="td1">ID (Payment Method)

</td><td class="td1">**/services/payment-methods**

</td><td class="td1">Master Party Payment Method

</td><td class="td1">external\_payment\_id

</td><td class="td1">Haupt-ID

</td></tr><tr><td class="td1">Type

</td><td class="td1">**/services/payment-methods**

</td><td class="td1">Master Party Payment Method

</td><td class="td1">payment\_type

</td><td class="td1">z. B. SEPA / Direct Debit

</td></tr></tbody></table>

Then:

<table class="t1" id="bkmrk-gridware-feld-api-ad-1"><tbody><tr><td class="td1">**Gridware Feld**

</td><td class="td1">API adress

</td><td class="td1">**Ziel-Doctype**

</td><td class="td1">**Ziel-Feld in ERPNext**

</td><td class="td1">**Bemerkung**

</td></tr><tr><td class="td1">Iban

</td><td class="td1">**/services/payment-methods/ID**

</td><td class="td1">Master Party Payment Method

</td><td class="td1">iban

</td><td class="td1">Wichtig für Bankkonto

</td></tr><tr><td class="td1">BankName

</td><td class="td1">**/services/payment-methods/ID**

</td><td class="td1">Master Party Payment Method

</td><td class="td1">bank\_name

</td><td class="td1">Falls Detail-Endpoint das liefert

</td></tr><tr><td class="td1">MandateID

</td><td class="td1">**/services/payment-methods/ID**

</td><td class="td1">Master Party Payment Method

</td><td class="td1">mandate\_id

</td><td class="td1">Wichtig für SEPA Mandate

</td></tr><tr><td class="td1">CreatedAt

</td><td class="td1">**/services/payment-methods/ID**

</td><td class="td1">Master Party Payment Method

</td><td class="td1">created\_at

</td><td class="td1"></td></tr><tr><td class="td1">erzeugtes ERPNext Bank Account

</td><td class="td1">LINK

</td><td class="td1">Master Party Payment Method

</td><td class="td1">erpnext\_bank\_account

</td><td class="td1">Optional nachgelagert

</td></tr><tr><td class="td1">erzeugtes ERPNext SEPA Mandate

</td><td class="td1">LINK

</td><td class="td1">Master Party Payment Method

</td><td class="td1">erpnext\_sepa\_mandate

</td><td class="td1">Optional nachgelagert

</td></tr></tbody></table>

# New DocTypes: Gridware Contract, Gridware Usage

**Gridware Contract:**

<div drawio-diagram="154"><img src="https://becharged.phamos.eu/uploads/images/drawio/2026-04/drawing-11-1776162063.png" alt="drawing-11-1776162063.png"/></div>

**Gridware Usage:**

<div drawio-diagram="163"><img src="https://becharged.phamos.eu/uploads/images/drawio/2026-04/drawing-11-1777469548.png" alt="drawing-11-1777469548.png"/></div>

# Arbeitspaket Vorbereitung: Contracts & Batches

<div drawio-diagram="162"><img src="https://becharged.phamos.eu/uploads/images/drawio/2026-04/drawing-11-1777371127.png" alt="drawing-11-1777371127.png"/></div>

##### **Contract Types via Contract API:**

**USAGE\_HUBJECT\_CPO\_ROAMING**

- Invoicing Party to Customer: external EMP (Grid&amp;Co) because its his customers
- Contract in Gridware:<span class="Apple-converted-space"> </span>Hubject CPO roaming for external EMPs
- What needs to be done in ERP Next is: 
    - Money In: EMP (Contractor) in this case Grid&amp;Co receives Invoice —&gt; [**M100068: Leistungen EMP / Roaming**](https://erpnext.becharged.de/app/item/M100068)
    - Money Out: CPO (Supplier) receive credit note —&gt; [**M100053: Ladevorgänge Roaming**](https://erpnext.becharged.de/app/item/M100053)[![ContractNueterg BEC-V-89901595.png](https://becharged.phamos.eu/uploads/images/gallery/2026-05/scaled-1680-/contractnueterg-bec-v-89901595.png)](https://becharged.phamos.eu/uploads/images/gallery/2026-05/contractnueterg-bec-v-89901595.png)

**USAGE\_POSTPAID**

- Invoicing Party to Customer: becharged via SEPA or Invoicing
- In Gridware:<span class="Apple-converted-space"> </span>Usage contract (billable)
- What needs to be done in ERP Next is: 
    - Money In: Every Contract Customer receives Invoice —&gt;<span class="Apple-converted-space"> </span>[<span class="s2">**M100055: Ladevorgänge Vertragsladen**</span>](https://erpnext.becharged.de/app/item/M100055)
    - Money out: CPO (Supplier) receives credit note —&gt; [<span class="s2">**M100055: Ladevorgänge Vertragsladen**</span>](https://erpnext.becharged.de/app/item/M100055)[![524 BEC-V-08001523,.png](https://becharged.phamos.eu/uploads/images/gallery/2026-05/scaled-1680-/524-bec-v-08001523.png)](https://becharged.phamos.eu/uploads/images/gallery/2026-05/524-bec-v-08001523.png)

**USAGE\_POSTPAID CC (Company Car)**

 \* Speciality: 0% VAT   
 \* Supplier is the employee that drives the company car, customer is company that pays for electricity, Elsewise same handling as normal Usage\_postpaid

[![BillingPeriod THONTHLY,.png](https://becharged.phamos.eu/uploads/images/gallery/2026-05/scaled-1680-/billingperiod-thonthly.png)](https://becharged.phamos.eu/uploads/images/gallery/2026-05/billingperiod-thonthly.png)

**AUTHORIZATION**

- Invoicing Party to Customer: No one because its not billed
- In Gridware: Authorization contract
- What needs to be done in ERP Next is:<span class="Apple-converted-space"> </span>Store usage and contract information

[![Screenshot 2026-05-07 at 12.14.16.png](https://becharged.phamos.eu/uploads/images/gallery/2026-05/scaled-1680-/screenshot-2026-05-07-at-12-14-16.png)](https://becharged.phamos.eu/uploads/images/gallery/2026-05/screenshot-2026-05-07-at-12-14-16.png)

**USAGE\_ADHOC**

- Invoicing Party to Customer: becharged through pay as you go
- In Gridware: Adhoc usage contract
- What needs to be done in ERP Next is: 
    - Money In: Anonymous Customers pay via PayPal, Stripe or Payter and receive a receipt
    - Money out: CPO (Supplier) receives credit note —&gt; <span class="s2">**M100034: Ladevorgänge AdHoc-Laden**</span>

[![Screenshot 2026-05-07 at 12.14.50.png](https://becharged.phamos.eu/uploads/images/gallery/2026-05/scaled-1680-/screenshot-2026-05-07-at-12-14-50.png)](https://becharged.phamos.eu/uploads/images/gallery/2026-05/screenshot-2026-05-07-at-12-14-50.png)

**EMP\_USAGE\_INTERNAL**

- Similar to Usage Postpaid, but with different offers and pricing
- Invoicing Party to Customer: becharged via SEPA or Invoicing
- In Gridware: EMP contract
- What needs to be done in ERP Next is: 
    - Money In: Every Contract Customer receives Invoice —&gt;<span class="Apple-converted-space"> </span>[<span class="s2">**M100055: Ladevorgänge Vertragsladen**</span>](https://erpnext.becharged.de/app/item/M100055)
    - Money out: CPO (Supplier) receives credit note —&gt; [<span class="s2">**M100034: Ladevorgänge AdHoc-Laden**</span>](https://erpnext.becharged.de/app/item/M100034)

[![PantractTya!. EMp USAGE INTERNAL.png](https://becharged.phamos.eu/uploads/images/gallery/2026-05/scaled-1680-/pantracttya-emp-usage-internal.png)](https://becharged.phamos.eu/uploads/images/gallery/2026-05/pantracttya-emp-usage-internal.png)

# MVP Kundenportal

<div drawio-diagram="180"><img src="https://becharged.phamos.eu/uploads/images/drawio/2026-05/drawing-11-1779793410.png" alt="drawing-11-1779793410.png"/></div>

# MVP-Konzept: Kundenportal auf Basis von ERPNext für Dienstwagen &amp; Ladestationen

## Ziel des MVP

Ziel ist die Entwicklung eines Kundenportals auf Basis des bestehenden ERPNext-Ticketsystems, um aktuell manuelle Prozesse rund um Dienstwagen und Ladestationen zu digitalisieren und zu automatisieren.

Der Fokus des MVP liegt darauf:

- PDF-basierte Datenerfassung durch digitale Webformulare zu ersetzen
- doppelte manuelle Dateneingaben zu vermeiden
- Datensätze automatisiert in ERPNext anzulegen
- Daten automatisiert nach Gridware zu übertragen
- Prozesszeiten und Fehlerquellen zu reduzieren
- einen zentralen Self-Service-Bereich für Kunden bereitzustellen

---

# Zusammenfassung der aktuellen Prozesse

## Prozess 1: Dienstwagenanlage

### Aktueller Prozess

1. Der Fuhrparkmanager meldet sich bzw. kontaktiert BeCharged.
2. Eine PDF mit den relevanten Informationen wird an Matthias geschickt.
3. Matthias überträgt die Informationen manuell aus der PDF in Gridware.
4. Die Daten werden dort über ein bestehendes Webformular eingepflegt.
5. Erst danach wird der Kundendatensatz in Gridware angelegt.

### Probleme im aktuellen Prozess

- Medienbruch zwischen PDF und System
- hoher manueller Aufwand
- doppelte Dateneingabe
- Fehleranfälligkeit durch manuelles Abtippen
- keine direkte Kundenschnittstelle
- keine standardisierte Datenerfassung

### Zielprozess (Soll-Prozess)

1. Der Fuhrparkmanager meldet sich im ERPNext-Kundenportal an.
2. Das Formular „Dienstwagen“ wird direkt online ausgefüllt.
3. Die Daten werden automatisiert in ERPNext gespeichert.
4. Automatisch wird ein Kundendatensatz erstellt.
5. Die Daten werden anschließend automatisiert nach Gridware übertragen.
6. Gridware wird dadurch zum nachgelagerten System.

---

## Prozess 2: Anlage &amp; Pflege von Ladestationen

### Aktueller Prozess

1. Ein Angebot wird an den Kunden verschickt.
2. Gemeinsam mit dem Angebot wird eine PDF zur Datenerfassung versendet.
3. Der Betreiber der Ladestation füllt die PDF aus.
4. Die Informationen werden manuell in ERPNext übertragen.
5. Anschließend wird ein Auftrag erstellt.
6. Danach werden die Daten zusätzlich in Gridware angelegt.
7. Anschließend wird ein Starter-Kit (SIM-Karten, Ladekarten, Sticker etc.) an den Kunden versendet.

### Probleme im aktuellen Prozess

- manueller PDF-Prozess
- redundante Dateneingabe
- fehlende Systemautomatisierung
- hoher operativer Aufwand
- keine zentrale Datenbasis
- verzögerte Auftragsbearbeitung

### Zielprozess (Soll-Prozess)

1. Der Kunde erhält Zugriff auf ein digitales Formular im ERPNext-Portal.
2. Die bisherige PDF wird vollständig durch ein Webformular ersetzt.
3. Der Kunde trägt alle relevanten Daten direkt online ein.
4. Die Daten werden automatisiert in ERPNext gespeichert.
5. Auf Basis der Daten können direkt Angebot und Auftrag erstellt werden.
6. Die relevanten Informationen werden automatisiert nach Gridware übertragen.
7. Anschließend wird automatisiert bzw. operativ das Starter-Kit versendet.

---

# Ergänzende Erkenntnisse aus Audioanalyse (Teil 1)

## Wichtige fachliche Erkenntnisse

### 1. ERPNext soll zum führenden System werden

Aus der Audio wird deutlich, dass aktuell viele Stammdaten erst verspätet oder indirekt entstehen. Zielbild ist eindeutig:

- ERPNext wird zentrale Datenbasis
- Gridware wird nachgelagertes System
- Daten sollen nur einmal eingegeben werden
- manuelles Abtippen soll vollständig entfallen

Besonders wichtig:

Aktuell entstehen wichtige Stammdaten oft erst im Angebot- oder Auftragsprozess. Dies führt zu redundanten Schritten und Medienbrüchen.

---

## 2. Kundenportal als zentraler Einstiegspunkt

Das bestehende Kundenportal soll erweitert werden.

Neue Anforderungen:

- Kunden sollen sich selbst anmelden können
- Fuhrparkmanager erhalten eigene Zugänge
- Betreiber von Ladestationen erhalten eigene Zugänge
- bestehende Kunden sollen mehrere Vorgänge verwalten können
- Formulare sollen direkt im Portal verfügbar sein
- Kunden sollen bestehende Datensätze ergänzen oder ändern können

Zusätzliche Perspektive:

Langfristig ist eine Single-Sign-On-Logik zwischen Gridware und ERPNext angedacht.

---

## 3. Ticketsystem-Integration ist strategisch wichtig

Die Lösung soll nicht nur Formulare abbilden, sondern eng mit dem bestehenden Ticketsystem verknüpft werden.

Dadurch sollen:

- Vorgänge nachvollziehbar werden
- Bearbeitungsstände sichtbar sein
- Kommunikation zentral dokumentiert werden
- interne Bearbeitung vereinfacht werden
- spätere Supportprozesse integriert werden

Wichtige Erkenntnis:

Die Formulare sind nicht isolierte Eingabemasken, sondern sollen direkt mit Ticket-Workflows verbunden werden.

---

## 4. Dienstwagen-Prozess: Erweiterte Anforderungen

### Zusätzliche Erkenntnisse

- Fuhrparkmanager sind externe Ansprechpartner auf Kundenseite
- diese verwalten neue Mitarbeitende/Fahrzeuge
- aktuelle PDFs enthalten bereits alle notwendigen Daten
- Matthias übernimmt aktuell lediglich das manuelle Übertragen der Daten
- zukünftig soll die Eingabe vollständig durch den Kunden selbst erfolgen

### Neue MVP-Anforderungen

- Anlage von Unternehmen/Kunden im Portal
- Anlage mehrerer Nutzer pro Unternehmen
- Verwaltung von Dienstwagen pro Unternehmen
- Statusübersicht pro Dienstwagenvorgang
- Rückschreiben von Informationen an Kunden
- spätere Änderungsmöglichkeiten bestehender Datensätze

---

## 5. Ladestationen-Prozess: Erweiterte Anforderungen

### Wichtige Prozesslogik

Der Prozess startet aktuell meist über:

1. Kontaktaufnahme
2. Angebot
3. PDF-Versand
4. Rücksendung ausgefüllter Daten
5. manuelle Übertragung
6. Auftragserstellung
7. Gridware-Anlage
8. Versand Starter-Kit

### Kritischer Pain Point

Die Datenerfassung passiert aktuell zu spät im Prozess.

Viele Informationen werden erst nach Angebot oder Auftrag eingeholt.

Dadurch entstehen:

- unnötige Rückfragen
- doppelte Datenerfassung
- Verzögerungen
- fehlende Stammdaten

### Neue MVP-Anforderungen

- frühzeitige strukturierte Datenerfassung
- zentrale Speicherung aller Standortdaten
- technische Datenverwaltung pro Ladestation
- Betreiberdaten direkt im Portal erfassbar
- Zuordnung mehrerer Ladestationen zu einem Kunden
- Verwaltung verschiedener Ladestationstypen
- Übergabe aller Daten an Gridware

---

## 6. Starter-Kit-Prozess muss berücksichtigt werden

Die Audio zeigt, dass der Versand des Starter-Kits operativ relevant ist.

### Bestandteile des Starter-Kits

- SIM-Karten
- Ladekarten
- Sticker/Aufkleber
- Freischaltinformationen

### Neue Anforderungen

- Versandstatus dokumentieren
- Versandinformationen speichern
- Trigger für Versandprozess
- Adressvalidierung
- optional Tracking/Status

---

## 7. Formulare müssen dynamisch sein

Die Audio deutet darauf hin, dass unterschiedliche Varianten und Ausprägungen existieren.

Daraus ergeben sich folgende Anforderungen:

- dynamische Formularfelder
- bedingte Felder
- unterschiedliche Formulartypen
- Vorbefüllung bestehender Kundendaten
- Wiederverwendbarkeit bestehender Daten

---

## 8. Datenqualität &amp; Automatisierung sind Hauptziel

Das eigentliche strategische Ziel scheint nicht nur Digitalisierung zu sein, sondern:

- Vermeidung redundanter Datenerfassung
- saubere Stammdatenpflege
- höhere Datenqualität
- operative Entlastung
- bessere Skalierbarkeit
- durchgängige Prozesskette

---

## 9. Potenzielle Rollen im MVP

### Externe Rollen

- Fuhrparkmanager
- Ladestationsbetreiber
- Kundenadministrator

### Interne Rollen

- Operations
- Support
- Vertrieb
- Administration
- Versand/Starter-Kit-Bearbeitung

---

## 10. Technische Architektur-Anforderungen

### Integrationen

- ERPNext ↔ Gridware
- ERPNext Ticketsystem
- Kundenportal
- Dokumentenmanagement

### Zukünftige Optionen

- Single Sign-On
- API-basierte Synchronisation
- automatisierte Statusupdates
- E-Mail-Automatisierung
- Workflow-Engine

---

## 11. Offene Fragen für die nächste Workshoprunde

### Fachlich

- Welche Felder sind Pflichtfelder?
- Welche Daten müssen nach Gridware synchronisiert werden?
- Welche Status gibt es genau?
- Welche Rollen dürfen welche Daten bearbeiten?
- Welche Daten dürfen Kunden nachträglich ändern?
- Welche Dokumente müssen hochgeladen werden?

### Technisch

- Gibt es bereits APIs zu Gridware?
- Erfolgt Synchronisation synchron oder asynchron?
- Wie sieht Fehlerhandling aus?
- Wie werden Dubletten verhindert?
- Welche Datenobjekte sind führend?

---

# Übergeordneter MVP-Anforderungskatalog

## 1. Benutzer- &amp; Portalmanagement

### Muss-Anforderungen

- Kundenlogin für externe Nutzer
- Rollen- und Rechteverwaltung
- Passwort-Reset-Funktion
- DSGVO-konforme Benutzerverwaltung
- Kunden können ausschließlich ihre eigenen Datensätze sehen

### Optional für spätere Phasen

- Multi-User-Zugänge pro Kunde
- Freigabeprozesse
- SSO / Microsoft Login

---

## 2. Webformulare

### Formular 1: Dienstwagen

#### Anforderungen

- Digitales Formular innerhalb des ERPNext-Portals
- Pflichtfelder definierbar
- Validierung von Eingaben
- Upload-Möglichkeit für Dokumente
- Speicherung aller Daten in ERPNext
- Automatische Erstellung eines Kundendatensatzes
- Übergabe relevanter Daten an Gridware
- Statusverfolgung des Vorgangs

#### Mögliche Formularfelder

- Kundendaten
- Ansprechpartner
- Fahrzeugdaten
- Fahrerinformationen
- Abrechnungsinformationen
- Vertragsdaten
- Sonstige Zusatzinformationen

---

### Formular 2: Ladestationen

#### Anforderungen

- Ersatz der bestehenden PDF durch Webformular
- Strukturierte Datenerfassung
- Speicherung in ERPNext
- Automatische Erstellung relevanter Datensätze
- Grundlage zur Angebots- und Auftragserstellung
- Übergabe an Gridware
- Upload-Möglichkeit für technische Dokumente/Bilder
- Statusübersicht für Kunden

#### Mögliche Formularfelder

- Standortdaten
- Betreiberdaten
- technische Daten der Ladestation
- Netzanschlussinformationen
- Ansprechpartner
- gewünschte Services
- Lieferinformationen
- Versandinformationen für Starter-Kit

---

## 3. ERPNext Integration

### Muss-Anforderungen

- Speicherung aller Formulardaten in ERPNext
- Automatische Erstellung von:
    
    
    - Kundendatensätzen
    - Angeboten
    - Aufträgen
    - Tickets / Vorgängen
- Workflow-Unterstützung
- Nachvollziehbarkeit aller Änderungen
- Historisierung der Eingaben

---

## 4. Gridware Integration

### Muss-Anforderungen

- Schnittstelle zwischen ERPNext und Gridware
- Automatische Datenübertragung
- Fehlerhandling bei fehlgeschlagenen Übertragungen
- Logging der Synchronisation
- Vermeidung manueller Doppelpflege

### Zielarchitektur

ERPNext wird führendes System.

Gridware wird ausschließlich mit relevanten Daten aus ERPNext versorgt.

---

## 5. Prozessautomatisierung

### MVP-Automatisierungen

- automatische Datensatzanlage
- automatische Statusänderungen
- automatische Übergabe an Gridware
- automatische Erstellung von Angeboten/Aufträgen
- Benachrichtigungen an interne Mitarbeitende
- Benachrichtigungen an Kunden

---

## 6. Ticket- &amp; Statussystem

### Anforderungen

- Jeder Vorgang erhält eine eindeutige Ticketnummer
- Statusübersicht für Kunden
- Statusübersicht für interne Teams
- Nachverfolgung offener Aufgaben
- Kommentarfunktion (optional)

### Beispielstatus

- Entwurf
- Eingereicht
- In Bearbeitung
- Synchronisiert mit Gridware
- Auftrag erstellt
- Starter-Kit versendet
- Abgeschlossen

---

## 7. Dokumentenmanagement

### Anforderungen

- Upload von PDFs/Bildern
- Speicherung im jeweiligen Vorgang
- Downloadmöglichkeit
- Versionierung (optional)

---

## 8. Reporting &amp; Administration

### Anforderungen

- Übersicht aller eingereichten Vorgänge
- Filter- und Suchfunktion
- Exportfunktion
- Bearbeitungsstatus einsehbar
- Admin-Ansicht für interne Teams

---

# Prozesszeichnungen

## Prozess 1 – Dienstwagen

### IST-Prozess

```text
Fuhrparkmanager
        ↓
PDF wird an Matthias geschickt
        ↓
Matthias überträgt Daten manuell
        ↓
Manuelle Eingabe in Gridware
        ↓
Kundendatensatz entsteht in Gridware

```

### SOLL-Prozess

```text
Fuhrparkmanager loggt sich im Portal ein
        ↓
Webformular „Dienstwagen“ ausfüllen
        ↓
Daten werden in ERPNext gespeichert
        ↓
Automatische Kundendatensatz-Erstellung
        ↓
Automatische Synchronisation zu Gridware
        ↓
Vorgang abgeschlossen

```

---

## Prozess 2 – Ladestationen

### IST-Prozess

```text
Angebot wird verschickt
        ↓
PDF zur Datenerfassung wird mitgeschickt
        ↓
Kunde füllt PDF aus
        ↓
Manuelle Übertragung in ERPNext
        ↓
Auftrag wird erstellt
        ↓
Daten werden zusätzlich in Gridware angelegt
        ↓
Starter-Kit wird versendet

```

### SOLL-Prozess

```text
Kunde erhält Zugriff auf Webformular
        ↓
Ladestationsdaten werden online eingegeben
        ↓
Daten werden in ERPNext gespeichert
        ↓
Automatische Erstellung von Angebot/Auftrag
        ↓
Automatische Synchronisation nach Gridware
        ↓
Starter-Kit Versandprozess startet
        ↓
Vorgang abgeschlossen

```

---

# Empfehlung für die MVP-Umsetzung

## Phase 1 – MVP

Fokus auf:

- Kundenportal
- Login &amp; Rechte
- beide Webformulare
- ERPNext-Datenspeicherung
- grundlegende Gridware-Schnittstelle
- Basis-Workflow &amp; Statusmanagement

## Phase 2 – Erweiterungen

Mögliche Erweiterungen:

- automatisierte E-Mail-Strecken
- digitale Freigaben
- Dokumentengenerator
- Signaturprozesse
- Dashboard &amp; Analytics
- Self-Service-Verwaltung bestehender Datensätze
- API-Erweiterungen
- mobile Optimierung

---

# Ergänzende Erkenntnisse aus Audioanalyse (Teil 2)

## 12. MVP soll bewusst als Demo-/Proof-of-Concept aufgebaut werden

Aus Teil 2 wird deutlich:

Der erste MVP dient primär dazu, intern zu demonstrieren, wie ERPNext, Kundenportal, Formulare und Automatisierung zusammenspielen können.

Das Ziel des ersten MVPs ist daher nicht Vollständigkeit, sondern:

- Machbarkeit zeigen
- Prozessverständnis schaffen
- interne Stakeholder überzeugen
- Vorteile sichtbar machen
- operative Entlastung demonstrieren

Wichtige Erkenntnis:

Es reicht zunächst ein kleiner funktionaler Showcase.

---

## 13. Strategischer Fokus: Automatisierte Artikel- &amp; SIM-Kartenlogik

Ein zentrales Problem im aktuellen Prozess ist die manuelle Zuordnung von:

- SIM-Karten
- Ladekarten
- Wallbox-Konfigurationen
- Ladepunktdaten
- Links
- QR-Codes
- Starter-Kit-Komponenten

### Zielbild

Das System soll:

- Artikel automatisch auswählen
- richtige Konfigurationen zuordnen
- Fehler bei manueller Auswahl vermeiden
- Kontextinformationen automatisch generieren

Beispiel:

Wenn ein Kunde einen bestimmten Wallbox-Typ auswählt, sollen automatisch:

- passende SIM-Karte
- passende Konfiguration
- korrekte QR-Codes
- passende Anleitungen
- zugehörige Links

bereitgestellt werden.

---

## 14. Kundenportal soll operative Fehler reduzieren

Die Audio macht deutlich, dass aktuell viele Fehler entstehen durch:

- manuelles Abtippen
- falsche Zuordnung von Daten
- fehlende Stammdaten
- falsche SIM-Karten
- falsche Ladepunkt-Zuordnungen
- Tippfehler bei Links
- Copy/Paste-Prozesse

Das Portal soll diese Risiken eliminieren.

---

## 15. Dynamische Verknüpfung von Kundendaten

Wichtige neue Anforderung:

Wenn ein Kunde bereits existiert:

- sollen bekannte Daten vorbefüllt werden
- bestehende Vertragsdaten genutzt werden
- bestehende Abrechnungsdaten übernommen werden
- bekannte Ladepunkte wiederverwendet werden

Das reduziert:

- doppelte Eingaben
- Fehler
- Prozessdauer

---

## 16. Formularlogik soll intelligent werden

Die Audio zeigt, dass Formulare nicht statisch gedacht sind.

### Anforderungen

Formulare sollen abhängig von:

- Kundentyp
- Produkt
- Ladepunkt-Typ
- Vertragsmodell
- Betreiberrolle
- Standort

unterschiedliche Felder und Prozesse anzeigen.

### Beispiele

- unterschiedliche Wallbox-Typen
- verschiedene SIM-Konfigurationen
- verschiedene Starter-Kits
- unterschiedliche Aktivierungsprozesse

---

## 17. QR-Code- &amp; Link-Management ist ein zentraler Bestandteil

Die Audio zeigt einen bisher nicht erkannten wichtigen Prozess:

### Aktueller Zustand

- Kunden erhalten QR-Codes und Links manuell
- diese müssen teilweise abgetippt werden
- fehleranfällig
- umständlich
- schlecht dokumentiert

### Zielzustand

QR-Codes und Aktivierungslinks sollen:

- automatisch generiert
- automatisch zugeordnet
- im Kundenportal sichtbar
- direkt anklickbar
- pro Ladepunkt eindeutig

sein.

---

## 18. Inbetriebnahme-Prozess der Ladestationen

Ein wichtiger Teilprozess wurde deutlich:

### Aktueller Prozess

1. Starter-Kit wird verschickt
2. Kunde erhält QR-Codes/Links
3. Kunde aktiviert Wallbox/Ladepunkt
4. Teilweise manuelle Eingaben notwendig
5. Konfiguration wird aktiviert

### Probleme

- manuelle Eingaben
- fehlerhafte Aktivierung
- fehlende Transparenz
- hoher Supportaufwand

### MVP-Ziel

- geführter Aktivierungsprozess
- direkte Verlinkungen
- eindeutige Ladepunkt-Zuordnung
- weniger manuelle Eingaben

---

## 19. Kundenportal soll perspektivisch Wissensplattform werden

Die Audio zeigt, dass aktuell viele Informationen intern als:

- Notizen
- Wissenslisten
- Schritt-für-Schritt-Anleitungen
- interne Dokumentationen

geführt werden.

### Zielbild

Das Kundenportal soll perspektivisch:

- Anleitungen bereitstellen
- Schritt-für-Schritt-Prozesse zeigen
- Dokumentationen bündeln
- Self-Service ermöglichen

### Mögliche Inhalte

- Inbetriebnahme-Anleitungen
- Ladepunkt-Aktivierung
- SIM-Karten-Aktivierung
- Fehlerbehebung
- FAQ
- Statusinformationen

---

## 20. Portalstruktur / mögliche UX-Struktur

Die Audio deutet bereits eine sinnvolle Struktur an:

### Beispielhafte Navigation

#### Dashboard

- offene Vorgänge
- Statusübersicht
- letzte Aktivitäten

#### Dienstwagen

- neue Dienstwagen anlegen
- bestehende verwalten
- Status einsehen

#### Ladestationen

- neue Ladestation anlegen
- Ladepunkte verwalten
- Aktivierungsstatus
- QR-Codes &amp; Links

#### Dokumente

- Aufträge
- Verträge
- Anleitungen
- Starter-Kit-Informationen

#### Support / Tickets

- Tickets einsehen
- Rückfragen
- Kommunikation

---

## 21. ERPNext soll operative Intelligenz abbilden

Das Ziel ist nicht nur Datenspeicherung.

ERPNext soll operative Regeln kennen:

- Welche SIM gehört zu welcher Wallbox?
- Welche Konfiguration wird benötigt?
- Welche Ladepunkte gehören zu welchem Kunden?
- Welche Artikel müssen verschickt werden?
- Welche Schritte fehlen noch?

Damit entsteht:

- Prozessautomatisierung
- Fehlervermeidung
- Standardisierung
- bessere Skalierung

---

## 22. MVP-Umsetzungsempfehlung (technisch)

### Empfohlener MVP-Umfang

#### Phase 1

- Kundenportal aktivieren
- Login-System
- Dienstwagen-Formular
- Ladestationen-Formular
- Datenspeicherung in ERPNext
- Basis-Ticketlogik
- Gridware-Export

#### Phase 2

- automatische Artikelzuordnung
- QR-Code-Management
- Starter-Kit-Management
- Statusautomatisierung
- Wissensdatenbank
- Aktivierungsflows

#### Phase 3

- vollständige API-Integration
- Single Sign-On
- Self-Service-Administration
- Automatisierung komplexer Prozesse

---

## 23. Kritische Erfolgsfaktoren

### Fachlich

- klare Stammdatenstruktur
- eindeutige Verantwortlichkeiten
- saubere Rollenlogik
- einfache Bedienung

### Technisch

- stabile Schnittstelle zu Gridware
- eindeutige IDs
- saubere Synchronisierung
- Logging &amp; Fehlerhandling

### Operativ

- Akzeptanz interner Teams
- klare Prozesse
- gute UX für Kunden
- einfache Wartbarkeit

---

## 24. Wichtigste strategische Erkenntnis

Die Audio zeigt sehr deutlich:

Das eigentliche Ziel ist nicht nur ein Formularsystem.

Das Ziel ist:

- eine zentrale operative Plattform
- mit sauberer Stammdatenführung
- digitalisierten Kundenprozessen
- automatisierten Abläufen
- reduziertem Supportaufwand
- besserer Skalierbarkeit
- höherer Datenqualität
- Self-Service-Funktionalität

ERPNext wird damit perspektivisch zum operativen Kernsystem.

---

# Ergänzende Erkenntnisse aus Audioanalyse (Teil 3)

## 25. Das eigentliche Problem ist fehlende Zentralisierung

Teil 3 macht sehr deutlich:

Das Kernproblem ist inzwischen weniger die reine Dateneingabe, sondern die fehlende Zentralisierung von:

- Verträgen
- Ladepunkten
- Kundendaten
- Rechnungen
- SIM-Karten
- Aktivierungsdaten
- Betriebsführungsinformationen
- Supportinformationen
- Ladepunktgebühren
- Dokumentationen

Die Informationen liegen aktuell verteilt in:

- PDFs
- Excel-Dateien
- einzelnen ERPNext-Objekten
- Gridware
- internen Wissenslisten
- persönlichen Notizen
- E-Mails

Das erzeugt:

- fehlende Transparenz
- hohe Supportkosten
- redundante Arbeit
- hohe Fehleranfälligkeit
- Skalierungsprobleme

---

## 26. Kundenportal soll zentrale Informationsplattform werden

Die Audio bestätigt sehr klar:

Das Kundenportal soll perspektivisch zur zentralen Plattform für Kunden werden.

### Kunden sollen dort zukünftig sehen können:

- Verträge
- Rechnungen
- Ladepunkte
- Ladepunktgebühren
- Betriebsführungsinformationen
- Aktivierungsinformationen
- SIM-Karten
- Statusinformationen
- Dokumentationen
- Supportinformationen
- Tickets
- Aufträge
- Angebotsdaten

Dadurch entsteht:

- mehr Transparenz
- weniger Supportanfragen
- bessere Kundenerfahrung
- höhere Skalierbarkeit

---

## 27. Vertragsmanagement wird ein wichtiger zukünftiger Bestandteil

Aus der Audio ergibt sich:

Verträge spielen operativ eine deutlich größere Rolle als zunächst angenommen.

### Aktuelle Probleme

- Vertragsinformationen sind verteilt
- viele Informationen werden manuell gepflegt
- Ladepunktgebühren sind schwer nachvollziehbar
- Vertragsstände sind nicht zentral sichtbar
- wiederkehrende Positionen sind schwer verwaltbar

### Relevante Vertragsbestandteile

- Betriebsführungsverträge
- Ladepunktgebühren
- monatliche Gebühren
- einmalige Positionen
- wiederkehrende Positionen
- kundenspezifische Konditionen

### Neue Anforderungen

- Verträge zentral verwalten
- Vertragspositionen digital abbilden
- Zuordnung von Ladepunkten zu Verträgen
- Historisierung
- Sichtbarkeit für Kunden
- automatische Gebührenlogik

---

## 28. Ladepunktverwaltung wird ein zentrales Datenmodell

Die Audio zeigt:

Ladepunkte sind eines der wichtigsten Objekte im zukünftigen System.

### Pro Ladepunkt relevant

- Betreiber
- Standort
- technische Daten
- Aktivierungsstatus
- QR-Codes
- SIM-Karten
- Gebührenmodell
- Vertragszuordnung
- Wallbox-Typ
- Konfigurationsdaten
- Betriebsstatus

### Konsequenz

Die Ladepunktverwaltung sollte perspektivisch als eigenes zentrales Objektmodell aufgebaut werden.

---

## 29. ERPNext soll operative Übersicht schaffen

Ein großes Problem aktuell:

Mitarbeitende verlieren den Überblick.

Beispiele aus der Audio:

- welche Ladepunkte existieren
- welche Verträge gültig sind
- welche Gebühren aktiv sind
- welche SIM-Karten wohin gehören
- welche Rechnungen existieren
- welcher Status gerade gilt

### Zielbild

ERPNext/Kundenportal soll als zentrale Übersicht dienen.

---

## 30. Reduktion von Supportaufwand ist ein Kernziel

Die Audio macht deutlich:

Viele Supportanfragen entstehen nur, weil Informationen nicht zentral zugänglich sind.

### Typische Probleme

- Kunden finden Rechnungen nicht
- Kunden kennen Vertragsstatus nicht
- Aktivierungsdaten fehlen
- QR-Codes fehlen
- Ladekarten funktionieren nicht
- Zuordnungen sind unklar

### Ziel

Self-Service statt manueller Support.

---

## 31. PDF-basierte Prozesse sind strategischer Engpass

Die PDFs sind aktuell:

- Datenträger
- Wissensspeicher
- Prozessdokumentation
- Vertragsgrundlage
- technische Datensammlung

Dadurch entstehen enorme operative Probleme.

### Strategisches Ziel

Ablösung der PDFs durch:

- strukturierte Datensätze
- Formulare
- zentrale Objekte
- digitale Workflows
- standardisierte Prozesse

---

## 32. MVP soll klein starten, aber skalierbar gedacht werden

Wichtige Erkenntnis:

Es besteht Einigkeit darüber:

- klein starten
- schnell demonstrieren
- danach iterativ erweitern

### MVP-Ziel

Nicht Perfektion.

Sondern:

- Verständnis erzeugen
- Nutzen sichtbar machen
- Prozesse beweisen
- Akzeptanz schaffen
- technische Richtung validieren

---

## 33. Wichtige zukünftige Ausbaupotenziale

Die Audio deutet viele spätere Ausbaustufen an.

### Mögliche Erweiterungen

- Vertragsmanagement
- Rechnungsportal
- Ladepunktmanagement
- Aktivierungscenter
- Wissensdatenbank
- Betriebsführungsportal
- Supportcenter
- Dokumentencenter
- QR-Code-Management
- API-Integrationen
- Monitoring
- automatisierte Gebührenlogik

---

## 34. Zukünftige Systemrollen

### Kundenrollen

- Fuhrparkmanager
- Ladepunktbetreiber
- Projektverantwortliche
- technische Ansprechpartner
- Buchhaltung

### Interne Rollen

- Vertrieb
- Operations
- Support
- Projektmanagement
- Vertragsmanagement
- Logistik
- Technik

---

## 35. MVP-Demo soll visuell überzeugen

Die Audio zeigt:

Der MVP dient auch als visuelles Kommunikationsmittel.

Wichtig ist daher:

- modernes Kundenportal
- sichtbare Workflows
- nachvollziehbare Prozesse
- konkrete Beispielmasken
- echte Statusdarstellung
- verständliche Benutzerführung

Die Demo muss zeigen:

„So könnte eure zukünftige Arbeitsweise aussehen.“

---

## 36. Strategische Gesamtvision

Nach allen drei Audio-Teilen wird das eigentliche Zielbild deutlich:

### Zielbild

Eine zentrale digitale Plattform für:

- Kunden
- Fuhrparkmanagement
- Ladeinfrastruktur
- Betriebsführung
- Aktivierung
- Support
- Vertragsmanagement
- Dokumentation
- Abrechnung
- Self-Service

auf Basis von ERPNext.

---

## 37. Wichtigste Erkenntnis aus Teil 3

Das Projekt ist deutlich größer als:

„Wir bauen zwei Formulare.“

Tatsächlich geht es um:

- Digitalisierung operativer Kernprozesse
- zentrale Stammdatenführung
- Self-Service-Plattform
- Prozessautomatisierung
- Wissenszentralisierung
- operative Skalierbarkeit
- Reduktion manueller Arbeit
- langfristige Plattformstrategie

---

# Zielbild der zukünftigen Architektur

```text
Kunde / Fuhrparkmanager / Ladestationsbetreiber
                    ↓
            ERPNext Kundenportal
                    ↓
             Digitale Webformulare
                    ↓
                 ERPNext
     (führendes System / zentrale Datenbasis)
                    ↓
       Automatisierte Synchronisation
                    ↓
                 Gridware

```

---

# Erwarteter Mehrwert

## Operativer Mehrwert

- massive Reduktion manueller Arbeit
- weniger Fehlerquellen
- schnellere Bearbeitung
- standardisierte Prozesse
- bessere Nachvollziehbarkeit
- höhere Datenqualität

## Geschäftlicher Mehrwert

- skalierbare Prozesse
- bessere Kundenerfahrung
- geringere Betriebskosten
- zentrale Datenbasis
- schnellere Auftragsabwicklung
- bessere Transparenz für Kunden und interne Teams

# Kundenportal für die EGT

<div drawio-diagram="191"><img src="https://becharged.phamos.eu/uploads/images/drawio/2026-06/drawing-11-1782119054.png" alt="drawing-11-1782119054.png"/></div>

<div drawio-diagram="194"><img src="https://becharged.phamos.eu/uploads/images/drawio/2026-06/drawing-11-1782134567.png" alt="drawing-11-1782134567.png"/></div>

# Ladekarten-Bestellungen im Kundenportal

<div drawio-diagram="239"><img src="https://becharged.phamos.eu/uploads/images/drawio/2026-07/drawing-11-1785228901.png" alt="drawing-11-1785228901.png"/></div>

# Ticket: "reimbursement"

<div drawio-diagram="240"><img src="https://becharged.phamos.eu/uploads/images/drawio/2026-08/drawing-11-1786720087.png" alt="drawing-11-1786720087.png"/></div>

# New Page

<div drawio-diagram="246"><img src="https://becharged.phamos.eu/uploads/images/drawio/2026-09/drawing-11-1788877421.png" alt="drawing-11-1788877421.png"/></div>