Jeder kostenpflichtige Ladevorgang endet in einem Dokument, das festlegt, wer wem wie viel zahlt: dem Charge Detail Record, kurz CDR. Fahrer sehen ihn nie direkt, doch Rechnungen, Roaming-Abrechnungen, Steuermeldungen und Reklamationen basieren darauf. Fehlerhafte CDRs kosten unbemerkt Geld und belasten Partnerschaften.
Dieser Leitfaden erklärt, was ein CDR enthält, wie ein CSMS ihn aus OCPP-Daten erstellt und wie Sie CDRs mit Partnern abgleichen.
- Ein CDR ist der endgültige, unveränderliche Datensatz eines abgeschlossenen Ladevorgangs.
- Er entsteht aus OCPP-Transaktions- und Zählerdaten plus dem gültigen Tarif.
- Versendete CDRs werden nie bearbeitet; Korrekturen erfolgen über Gutschrift-CDRs.
- Ein monatlicher Abgleich mit Ihren eigenen Sitzungsdaten verhindert stille Erlösverluste.
Was ein CDR ist
Ein CDR beschreibt einen beendeten Ladevorgang: wer wo und wann geladen hat, wie viel Energie geliefert wurde, welche Preise galten und wie hoch der Gesamtbetrag ist. Im Roaming sendet der CPO CDRs an den EMP, der damit seinen Fahrer abrechnet und den CPO bezahlt. Intern ist derselbe Datensatz Basis Ihrer eigenen Rechnungen und Berichte. Das Live-Gegenstück während des Ladens ist das Session-Objekt, erklärt in unserem Leitfaden zu den OCPI-2.2.1-Modulen.
Wichtige Felder eines OCPI-CDR
| Feld | Inhalt |
|---|---|
| id | Eindeutige CDR-Kennung des CPO |
| start_date_time / end_date_time | Beginn und Ende in UTC |
| session_id | Verweis auf die zugehörige Session |
| cdr_token | Verwendetes Token: RFID-UID, App-Token und Vertrags-ID |
| auth_method | Art der Autorisierung, etwa Whitelist oder Echtzeit |
| cdr_location | Adresse, Koordinaten, EVSE-ID und Steckerdaten zum Ladezeitpunkt |
| currency und tariffs | Währung und angewandte Tarife |
| charging_periods | Zeitblöcke mit Energie-, Zeit- und Parkdimensionen |
| signed_data | Optionale signierte Messwerte zur Prüfung |
| total_cost, total_energy, total_time, total_parking_time | Summen für die Abrechnung |
| credit, credit_reference_id | Kennzeichnet einen Gutschrift-CDR und verweist auf das Original |
So erstellt ein CSMS einen CDR aus OCPP
- Start: Die Station sendet StartTransaction (OCPP 1.6J) oder ein TransactionEvent mit eventType Started (OCPP 2.0.1) mit Startzählerstand und autorisierter ID.
- Während des Ladens: MeterValues melden in konfigurierten Intervallen Energie, Leistung und teils den Ladezustand.
- Stopp: StopTransaction oder TransactionEvent Ended liefert den Endzählerstand, den Stoppgrund und gegebenenfalls Transaktionsdaten.
- Bepreisung: Das CSMS wendet den bei Sessionstart gültigen Tarif auf Energie, Dauer und Standzeit an.
- Abschluss: Der CDR wird erstellt, gespeichert und an Partner gesendet oder für Rechnungen genutzt.
Den Nachrichtenablauf beschreibt unser Beitrag zu StartTransaction und StopTransaction.
Ladeperioden: das unterschätzte Detail
Ein CDR ist mehr als eine Summe. Ladeperioden teilen den Vorgang in Blöcke, sobald sich eine preisrelevante Dimension ändert, etwa wenn ein Zeitfenster eines zeitvariablen Tarifs endet oder das Auto fertig geladen hat, aber eingesteckt bleibt. Partner rechnen den Preis anhand dieser Perioden nach. Passen Ihre Perioden nicht zum veröffentlichten Tarif, kann der EMP Ihre Summe nicht prüfen und reklamiert.
Gutschrift-CDRs und Korrekturen
Ein versendeter CDR ist endgültig. War etwas falsch, etwa ein Zählerfehler oder ein falsch angewandter Tarif, senden Sie einen Gutschrift-CDR, der das Original aufhebt, und danach einen neuen, korrekten CDR. So bleibt ein für beide Seiten nachvollziehbarer Prüfpfad. Ändern Sie Summen in Ihrer Datenbank niemals stillschweigend ohne passende Gutschrift.
Signierte Messwerte
In Märkten mit strengen Messrichtlinien können Stationen Zählerstände signieren, damit Fahrer oder Dritte prüfen können, dass Energiewerte nicht verändert wurden. Solche signierten Werte lassen sich im Feld signed_data des CDR transportieren. Zähler und Firmware müssen die Signatur unterstützen; prüfen Sie lokale Vorgaben und Ihre Hardware.
Häufige Ursachen falscher CDRs
- Fehlende Stopp-Transaktionen bei Neustart oder Verbindungsverlust, wodurch Sessions offen bleiben.
- Zählerstände, die nach einem Firmware-Update springen oder zurückgesetzt werden.
- Uhrzeitabweichungen der Station mit falschen Zeiten und falscher zeitvariabler Bepreisung.
- Tarifänderungen, die auf vorher begonnene Sessions angewandt werden.
- Standgebühren auf Basis der Steckzeit statt des Ladeendes, siehe Blockiergebühren.
- Doppelte CDRs nach Wiederholungen ohne Idempotenzprüfung.
Checkliste für den Abgleich
- Sessions je Partner im CSMS mit gesendeten und bestätigten CDRs vergleichen.
- Monatliche Gesamtenergie je Partner mit dessen Abrechnung abgleichen.
- Sessions mit null Energie, sehr langer Dauer oder negativen Werten untersuchen.
- Prüfen, dass jeder Gutschrift-CDR auf ein vorhandenes Original verweist.
- Mit jedem Partner eine Reklamationsfrist und einen Prozess vereinbaren und dokumentieren.
Aufbewahrung und Datenschutz
CDRs enthalten personenbezogene Daten wie Token-Kennungen und personenbezogene Standorte. Bewahren Sie sie so lange auf, wie steuerliche und vertragliche Pflichten es verlangen, beschränken Sie den Zugriff und wenden Sie Ihre DSGVO-Regeln auf Exporte und Partnerübermittlungen an.
Häufig gestellte Fragen
Wer erstellt den CDR?
Die Plattform des CPO, weil sie Station und Zählerdaten kontrolliert. Der EMP empfängt ihn und nutzt ihn zur Abrechnung.
Kann ein EMP einen CDR ablehnen?
Ein EMP kann einen CDR im Rahmen der Partnervereinbarung reklamieren. Saubere Tarife, korrekte Zählerdaten und klare Ladeperioden senken die Zahl der Reklamationen.
Wie schnell sollte ein CDR gesendet werden?
Sobald die Session abgeschlossen ist. Verzögerungen verursachen Abrechnungsrückstände beim EMP und erschweren den Abgleich.
Üreticy erstellt CDRs aus OCPP-Zählerdaten, wendet Ihre Tarife an und speichert vollständige Logs für Prüfungen und Partnerabgleich. Abrechnungs- und Reporting-Funktionen ansehen oder kontaktieren Sie uns.