Testen von Use Cases

Vertragsmanagement
TC 5.1: Contract Synchronisation (Einzeln)
Ziel: Vertrag wird aus Gridware nach ERPNext synchronisiert.
Testschritte:
Gehe zu becharged Settings → Feld "Gridware Contract ID"
Gib eine Contract ID ein (z.B. "12345")
Klicke Button "Fetch Contract by ID"
Validieren:
 Gridware Contract wurde erstellt (Name: "GWC-......")
 Alle Felder sind gefüllt: contract_id, contract_number, contract_type
 active_from / active_until sind gesetzt
 VAT ist korrekt übertragen
Erfolgskriterium: Contract ist bereit für Ladevorgang-Verarbeitung.
TC 5.2: Contract Customers Sync
Ziel: Kunden-Liste des Contracts wird synchronisiert.
Testschritte:
Öffne den Contract aus TC 5.1
Scrolla zu "Contract Customers" Tab
Validieren:
 Mindestens eine Zeile vorhanden
 customer_id, subject_id, subject_name sind gefüllt
 
gridware_party Link ist gesetzt (Background Job)
 
customer Link ist gesetzt zu ERPNext Customer
Erfolgskriterium: Alle Kunden sind korrekt verlinkt.
TC 5.3: Contract Supplier Sync
Ziel: Lieferant wird korrekt verlinkt.
Testschritte:
Öffne den Contract aus TC 5.1
Gehe zu "Supplier Details" Section
Validieren:
 
gridware_supplier_party ist gesetzt
 
supplier Link zeigt zu ERPNext Supplier
 Supplier Name ist korrekt
Erfolgskriterium: Supplier kann in Lieferantenabrechnung verwendet werden.
TC 5.4: Contract Usage Fetch
Ziel: Ladevorgänge für Contract werden abgerufen.
Testschritte:
Öffne Contract aus TC 5.1
Schaue in Links: "Usage" Sektion
Validieren:
 Mindestens ein Gridware Usage vorhanden
 Links zeigen zur Seite mit allen Usages
 Usages haben gridware_usage_id
Erfolgskriterium: Ladevorgänge sind synchronisiert.
Stammdatenverwaltung
TC 4.1: Gridware Party Synchronisation
Ziel: Stelle sicher, dass Parteien aus Gridware korrekt nach ERPNext synchronisiert werden.
Testschritte:
Öffne Contract aus TC 5.1
Wähle entweder einen Customer oder den Supplier
Öffne die Gridware Party 
Validieren:
 Gridware Party wurde in ERPNext erstellt (Name: "GDW-P-.....")
 display_name ist korrekt (z.B. "Tesla GmbH")
 is_customer = 1 oder is_supplier = 1 gesetzt
 gridware_customer_number / gridware_supplier_number sind gefüllt
Erfolgskriterium: Party-Datensatz ist vollständig mit allen Daten aus Gridware.
TC 4.2: Customer Auto-Erstellung aus Party
Ziel: Customer wird automatisch aus Gridware Party erstellt.
Testschritte:
Öffne die Gridware Party aus TC 5.1
Markiere: 
is_customer = 1
Speichere
Warte auf Background Job (oder triggere manuell: 
master_data_from_gridware_party())
Validieren:
 Ein neuer Customer wurde erstellt
 Customer Name = Gridware Party display_name
 
custom_gridware_party Link ist gesetzt auf die Party
 Kunde kann in Sales Invoice verwendet werden
Erfolgskriterium: Customer ist einsatzbereit ohne manuelle Nacharbeit.
TC 4.3: Contact Auto-Erstellung
Ziel: Kontaktperson wird automatisch aus Party erstellt.
Testschritte:
Erstelle neue Gridware Party mit 
party_kind = "Person"
Fülle: 
first_name = "Max", 
last_name = "Müller", 
email = "max@example.com"
Speichere
Validieren:
 Ein Contact wurde erstellt
 Contact Name = "Max Müller"
 Email ist gespeichert
 
custom_gridware_party ist gesetzt
Erfolgskriterium: Contact kann für Customer verwendet werden.
TC 4.4: SEPA Mandate Synchronisation
Ziel: SEPA Mandat wird korrekt synchronisiert.
Testschritte:
Synchronisiere eine Party mit Payment Methods
Gehe zur Gridware Party → Tab "Payment Method"
Validieren:
 Payment Method Row zeigt: payment_type, iban, bic, sepa_mandate_id
 
erpnext_sepa_mandate Link ist gesetzt
 ERPNext SEPA Mandate wurde erstellt
 Bank Account ist verlinkt
Erfolgskriterium: SEPA-Daten können in Sales Invoice verwendet werden.
Ladevorgang-Verarbeitung
TC 7.1: Usage Skeleton Creation
Ziel: Gridware Usage wird mit Status "Pending" erstellt.
Testschritte:
Öffne Gridware Usage List
Filtere nach: 
status = "Pending"
Öffne einen Usage
Validieren:
 gridware_usage_id ist eindeutig gefüllt
 gridware_contract ist verlinkt
 status = "Pending"
 Detail-Felder sind LEER: start, end, consumption_value_in_kwh, etc.
Erfolgskriterium: Skeleton-Format ist korrekt (nur ID + Contract).
TC 7.2: Usage Detail Fill (Async Job)
Ziel: Background Job füllt Usage-Details auf.
Testschritte:
Warte 1-2 Minuten nach TC 7.1
Aktualisiere den Usage (F5)
Validieren:
 status hat sich zu "Complete" geändert
 start ist gefüllt mit echtem Datetime
 end ist gefüllt
 consumption_value_in_kwh > 0
 usage_price_payment_amount > 0
 rental_object_display_name zeigt Ladesäule
Erfolgskriterium: Alle Daten aus Gridware API sind übernommen.
TC 7.3: Usage Price Details
Ziel: Kostenaufschlüsselung ist korrekt.
Testschritte:
Öffne einen "Complete" Usage
Gehe zu "Usage Price Details" Section
Validieren:
 total_fix_costs_excl_vat + total_energy_costs_excl_vat + ... = Gesamtnetto
 Brutto-Werte sind ca. 19% höher (bei 19% VAT)
 Beispiel: 100 € netto + 19 € VAT = 119 € brutto ✓
Erfolgskriterium: Kostenaddition ist mathematisch korrekt.
TC 7.4: Usage Wh → kWh Conversion
Ziel: Energiewert wird korrekt von Wh zu kWh konvertiert.
Testschritte:
Öffne einen "Complete" Usage
Vergleiche: consumption_value_in_wh vs. consumption_value_in_kwh
Validieren:
 consumption_value_in_kwh = consumption_value_in_wh / 1000
 Beispiel: 45000 Wh = 45 kWh ✓
Erfolgskriterium: Umrechnung ist korrekt.
TC 7.5: Usage Cent → Euro Conversion
Ziel: Preise werden korrekt von Cent zu Euro konvertiert.
Testschritte:
Öffne einen "Complete" Usage
Vergleiche: usage_price_payment_amount Wert
Validieren:
 Wenn API: 12500 Cent → DB: 125.00 € ✓
 Wert ist in korrektem Format (2 Dezimalstellen)
Erfolgskriterium: Währungsumrechnung ist korrekt.
TC 7.6: Failed Usage Retry
Ziel: Fehlgeschlagene Usages werden täglich wiederholt.
Testschritte:
Erstelle einen simulierten Failed Usage (manuell: status = "Failed")
Warte auf Scheduler (täglich)
Oder: Triggere manuell 
retry_failed_usage_completion()
Validieren:
 Status hat sich zu "Complete" geändert
 Error Log zeigt keine Fehler mehr
Erfolgskriterium: Automatische Wiederholung funktioniert.
Kundenabrechnung
TC 8.1: Auto-Fetch beim Öffnen
Ziel: Customer Usage Data holt automatisch Usages ab.
Testschritte:
Erstelle neue Customer Usage Data
Setze: customer = "Customer A", billing_period = "01/2026"
Speichere
Validieren:
 Ein Benachrichtigungs-Popup erscheint: "Auto-fetched X usage(s)"
 usage_details Tabelle ist NICHT leer
 Mindestens eine Zeile pro verfügbarem Usage
Erfolgskriterium: Auto-Fetch wurde triggert und hat Daten gefunden.
TC 8.2: Aggregation in usage_details
Ziel: Ladevorgänge werden korrekt in Child Table aggregiert.
Testschritte:
Öffne die Customer Usage Data aus TC 8.1
Schaue zu "Usage Details"
Validieren:
 Jede Zeile zeigt einen Usage
 gridware_usage Link ist gesetzt
 consumption_kwh ist > 0
 price_excl_vat ist > 0
 contract_type ist nicht leer
Erfolgskriterium: Alle Usages sind aggregiert.
TC 8.3: Item-Mapping
Ziel: Item Code wird korrekt aus Contract Type + VAT gemappt.
Testschritte:
Öffne Customer Usage Data aus TC 8.1
Schaue Spalte "item_code" in usage_details
Validieren:
 Jede Zeile hat einen item_code (z.B. "CHARGING-POSTPAID-19")
 item_code existiert in ERPNext Item Master
 Mapping ist logisch: USAGE_POSTPAID + 19% = CHARGING-POSTPAID-19
Erfolgskriterium: Item-Mapping wurde korrekt durchgeführt.
TC 8.4: Totals Calculation
Ziel: Gesamtzahlen werden korrekt berechnet.
Testschritte:
Öffne Customer Usage Data aus TC 8.1
Gehe zu "Totals" Section
Validieren (Beispiel mit 2 Usages):
 total_consumption = 45 + 30 = 75 kWh
 total_charging_sessions = 2
 total_price_excl_vat = SUM(price_excl_vat) von allen Details
 total_price_incl_vat = total_price_excl_vat * 1.19 (bei 19% VAT)
Erfolgskriterium: Alle Summen sind mathematisch korrekt.
TC 8.5: Price Details Breakdown
Ziel: Kostenaufschlüsselung wird korrekt summiert.
Testschritte:
Öffne Customer Usage Data aus TC 8.1
Gehe zu "Price Details" Section
Validieren:
 total_fix_costs_excl_vat = SUM aller Usage Fix Costs
 total_energy_costs_excl_vat = SUM aller Usage Energy Costs
 Summe aller Kosten = total_price_excl_vat
Erfolgskriterium: Kostenaufschlüsselung ist vollständig und korrekt.
TC 8.6: Duplicate Prevention
Ziel: Ein Usage kann nicht zweimal aggregiert werden.
Testschritte:
Erstelle eine zweite Customer Usage Data für denselben Customer/Period
Validieren:
 Auto-Fetch findet KEINE Usages (weil bereits aggregiert)
 Benachrichtigung: "No usages found"
Erfolgskriterium: Duplikate sind ausgeschlossen.
TC 8.7: Status Transition
Ziel: Status wird automatisch abgeleitet.
Testschritte:
Öffne Customer Usage Data aus TC 8.1
Status sollte "Uninvoiced" sein
Klicke "Create Sales Invoice"
Speichere Invoice als Draft
Validieren:
 Status ändert sich zu "Draft Invoice"
Submit Invoice
Validieren:
 Status ändert sich zu "Invoiced"
Erfolgskriterium: Status wird automatisch synchronisiert.
TC 8.8: Multiple Contracts Aggregation
Ziel: Mehrere Verträge werden korrekt aggregiert.
Voraussetzung: Customer hat 2 Contracts für Januar 2026
Contract 1: USAGE_POSTPAID, 19% VAT
Contract 2: AUTHORIZATION, 0% VAT
Testschritte:
Erstelle Customer Usage Data für diesen Customer
Validieren:
 usage_details hat mindestens 2 unterschiedliche contract_type Zeilen
 Zeilen sind nach Contract Type gruppiert
Erfolgskriterium: Mehrere Verträge sind gemeinsam abgerechnet.
TC 8.9: Sales Invoice Creation
Ziel: Sales Invoice wird aus Customer Usage Data erstellt.
Testschritte:
Öffne "Uninvoiced" Customer Usage Data
Klicke Button "Create Sales Invoice"
Validieren:
 Sales Invoice wird geöffnet (Draft Status)
 customer ist korrekt gesetzt
 Items sind gruppiert nach Contract Type + VAT
 Summe = total_price_excl_vat aus CUD
 custom_customer_usage_data Link ist gesetzt
Erfolgskriterium: Invoice ist korrekt vorbereitet und bereit zum Submit.
TC 8.10: Pending Usage Blockade
Ziel: Customer Usage Data kann nicht erstellt werden mit Pending Usages.
Testschritte:
Erstelle einen Usage mit status = "Pending"
Versuche Customer Usage Data zu erstellen
Validieren:
 Error-Nachricht: "Found X pending Gridware Usage record(s)"
 Customer Usage Data wird NICHT erstellt
Erfolgskriterium: Pending Usages werden blockiert.
Integrations-Tests (End-to-End)
E2E TC 1: Vollständiger Flow (Single Charging Session)
Szenario: Ein Ladevorgang eines Kunden in Januar 2026
Testschritte:
Party Sync: Synchronisiere Party (Kunde + Lieferant)
 Party vorhanden
Contract Sync: Synchronisiere Vertrag
 Contract vorhanden mit Kunden + Lieferant
Usage Sync: Warte auf Usage (Status: Pending → Complete)
 Usage vorhanden mit allen Details
Auto-Fetch: Erstelle Customer Usage Data
 Usage wurde aggregiert
Totals: Prüfe Gesamtzahlen
 total_consumption = 45 kWh
 total_price_excl_vat = 105.04 €
Invoice: Erstelle Sales Invoice
 Invoice zeigt 45 kWh
 Subtotal = 105.04 €
 Total (mit 19% VAT) = 125.00 €
Erfolgskriterium: Vollständiger Flow ohne Fehler.
E2E TC 2: Mehrere Ladevorgänge (Monthly Aggregation)
Szenario: 100 Ladevorgänge eines Kunden in Januar 2026
Testschritte:
Synchronisiere alle 100 Usages
Erstelle Customer Usage Data für Januar
Validieren:
 Alle 100 Usages sind aggregiert
 total_charging_sessions = 100
 total_consumption = 1.234 kWh (Beispiel)
 Keine Duplikate
Erstelle Sales Invoice
Validieren:
 Invoice zeigt alle Kosten
 Gruppiert nach Contract Type + VAT (z.B. 2-3 Zeilen)
Erfolgskriterium: Massenaggregation funktioniert.
E2E TC 3: Multiple Contracts Same Customer
Szenario: Kunde hat 3 Verträge, Ladevorgänge pro Vertrag
Testschritte:
Synchronisiere 3 Contracts für denselben Kunden
Synchronisiere Usages pro Contract
Erstelle Customer Usage Data
Validieren:
 Alle Contracts sind aggregiert
 Customer Usage Detail hat Zeilen pro Contract Type
 Totals addieren sich korrekt
Erstelle Sales Invoice
Validieren:
 Invoice hat separate Zeilen pro Contract Type
 Gesamtbetrag ist korrekt
Erfolgskriterium: Multi-Contract-Aggregation funktioniert.
E2E TC 4: USAGE_ADHOC Handling
Szenario: Kunde hat auch USAGE_ADHOC Ladevorgänge
Testschritte:
Synchronisiere Contract mit type = "USAGE_ADHOC"
Synchronisiere Usages
Erstelle Customer Usage Data
Validieren:
 USAGE_ADHOC Usages sind NICHT aggregiert
 Total enthält NICHT die USAGE_ADHOC Kosten
Erstelle Sales Invoice
Validieren:
 USAGE_ADHOC Zeilen sind NICHT in Invoice
Erfolgskriterium: USAGE_ADHOC wird korrekt ignoriert.
E2E TC 5: Fehlerbehandlung & Recovery
Szenario: API ist kurzzeitig nicht erreichbar
Testschritte:
Trenne API-Verbindung
Starte Usage Sync
Validieren:
 Usage Sync schlägt fehl
 Status = "Failed"
 Error Log zeigt API-Fehler
Stelle API-Verbindung wieder her
Warte auf Scheduler oder trigger 
retry_failed_usage_completion()
Validieren:
 Status ändert sich zu "Complete"
 Usage ist jetzt verfügbar
Erfolgskriterium: Error Recovery funktioniert.
E2E TC 6: SEPA Payment Integration
Szenario: Rechnung wird via SEPA bezahlt
Testschritte:
Erstelle und submit Sales Invoice (aus TC 8.9)
Validieren:
 custom_sepa_mandate_reference ist gesetzt vom Customer
Erstelle Payment Entry
Validieren:
 SEPA-Konto ist vorgewählt
 Mandat ist korrekt verlinkt
Submit Payment Entry
Validieren:
 Invoice ist bezahlt
 Status-Update
Erfolgskriterium: SEPA-Integration funktioniert end-to-end.
Performance-Tests
PT 1: Bulk Sync (1.000+ Usages)
Ziel: System verarbeitet große Mengen.
Testschritte:
Synchronisiere Contract mit 1.000+ Usages
Validieren:
 Sync fertig in <5 Minuten
 Keine Datenverluste
 Keine Duplikate
Erfolgskriterium: Performance ist akzeptabel.
PT 2: Aggregation Performance (100+ Sessions pro Customer)
Ziel: Customer Usage Data verarbeitet große Datenmengen.
Testschritte:
Erstelle Customer Usage Data mit 100+ Usages
Validieren:
 Aggregation fertig in <10 Sekunden
 Totals korrekt
 UI responsive
Erfolgskriterium: UI bleibt responsive.
Data Quality Tests
DQ 1: Datenintegrität
Testschritte:
Exportiere Customer Usage Data
Vergleiche mit Gridware Export
Validieren:
 Alle Usages vorhanden
 Keine fehlenden oder doppelten Daten
 Preise stimmen überein
DQ 2: Zahlen-Validierung
Testschritte:
Öffne mehrere Sales Invoices
Validieren:
 Jede Invoice = genau 1 Customer Usage Data
 Summen stimmen überein
 Keine mathematischen Fehler
Checkliste für Kundenabnahme
 Alle TC 4.x (Stammdaten) bestanden
 Alle TC 5.x (Vertragsmanagement) bestanden
 Alle TC 7.x (Ladevorgang-Verarbeitung) bestanden
 Alle TC 8.x (Kundenabrechnung) bestanden
 Alle E2E TCs bestanden
 Alle PT TCs bestanden
 Alle DQ TCs bestanden
 Keine kritischen Error-Logs
 Performance-Anforderungen erfüllt
 Go-Live freigegebe