Ogni sessione di ricarica a pagamento si chiude con un documento che stabilisce chi paga chi e quanto: il charge detail record, o CDR. Il conducente non lo vede mai, ma da esso dipendono fatture, regolamenti di roaming, adempimenti fiscali e contestazioni. Quando i CDR sono sbagliati, si perde denaro in silenzio e i rapporti con i partner ne risentono.
Questa guida spiega cosa contiene un CDR, come un CSMS lo costruisce dai dati OCPP e come riconciliarlo con i partner.
- Un CDR è il record definitivo e immutabile di una sessione conclusa.
- Nasce dai dati di transazione e di misura OCPP più la tariffa applicabile.
- Un CDR inviato non si modifica; le correzioni avvengono con CDR di storno.
- La riconciliazione mensile con i propri dati di sessione evita perdite di ricavi silenziose.
Cos'è un CDR
Un CDR descrive una sessione dopo la sua conclusione: chi ha ricaricato, dove, quando, quanta energia è stata erogata, quali prezzi erano applicati e qual è l'importo totale. Nel roaming il CPO invia i CDR all'MSP, che li usa per fatturare il proprio conducente e pagare il CPO. Internamente, lo stesso record è la base delle tue fatture e dei report. La controparte in tempo reale durante la ricarica è l'oggetto sessione, spiegato nella guida ai moduli OCPI 2.2.1.
I campi principali di un CDR OCPI
| Campo | Contenuto |
|---|---|
| id | Identificativo univoco del CDR assegnato dal CPO |
| start_date_time / end_date_time | Inizio e fine sessione in UTC |
| session_id | Collegamento alla sessione |
| cdr_token | Token usato: UID RFID, token di app e ID contratto |
| auth_method | Modalità di autorizzazione, per esempio whitelist o tempo reale |
| cdr_location | Indirizzo, coordinate, EVSE ID e connettore al momento della ricarica |
| currency e tariffs | Valuta e tariffe applicate |
| charging_periods | Blocchi temporali con dimensioni di energia, tempo e sosta |
| signed_data | Valori di misura firmati facoltativi per la verifica |
| total_cost, total_energy, total_time, total_parking_time | Totali usati per la fatturazione |
| credit, credit_reference_id | Indica un CDR di storno e lo collega all'originale |
Come un CSMS costruisce un CDR da OCPP
- Avvio: la colonnina invia StartTransaction (OCPP 1.6J) o un TransactionEvent con eventType Started (OCPP 2.0.1) con lettura iniziale e ID autorizzato.
- Durante la ricarica: i MeterValues riportano energia, potenza e talvolta stato di carica a intervalli configurati.
- Arresto: StopTransaction o TransactionEvent Ended fornisce la lettura finale, il motivo dell'arresto e, se configurati, i dati di transazione.
- Prezzo: il CSMS applica la tariffa valida all'inizio della sessione a energia, durata e tempo di sosta.
- Chiusura: il CDR viene creato, archiviato e inviato ai partner o usato per la fatturazione.
Il flusso dei messaggi è descritto nell'articolo su StartTransaction e StopTransaction.
I periodi di ricarica, il dettaglio nascosto
Un CDR non è solo un totale. I periodi di ricarica dividono la sessione ogni volta che cambia una dimensione rilevante per il prezzo, per esempio alla fine di una fascia oraria o quando l'auto ha finito di caricare ma resta collegata. I partner li usano per ricalcolare il prezzo. Se i periodi non corrispondono alla tariffa pubblicata, l'MSP non può verificare il totale e lo contesta.
CDR di storno e correzioni
Un CDR inviato è definitivo. Se qualcosa era sbagliato, come un errore del contatore o una tariffa applicata male, si invia un CDR di storno che annulla l'originale e poi un nuovo CDR corretto. In questo modo resta una traccia di audit seguibile da entrambe le parti. Non modificare mai in silenzio i totali nel tuo database senza uno storno corrispondente.
Valori di misura firmati
Nei mercati con regole metrologiche rigide, le colonnine possono firmare le letture del contatore, così il conducente o un terzo possono verificare che i valori non siano stati alterati. Questi valori firmati possono viaggiare nel campo signed_data del CDR. Contatore e firmware devono supportare la firma: verifica le norme locali e le capacità dell'hardware.
Cause frequenti di CDR errati
- Arresti di transazione mancanti dopo un riavvio o una perdita di connessione, con sessioni rimaste aperte.
- Letture del contatore che saltano o si azzerano dopo un aggiornamento firmware.
- Deriva dell'orologio della colonnina, con orari e prezzi a fasce sbagliati.
- Modifiche tariffarie applicate a sessioni iniziate prima del cambio.
- Penali di sosta calcolate sul tempo di collegamento invece che sulla fine della ricarica, vedi penali di sosta.
- CDR duplicati dopo nuovi tentativi senza controllo di idempotenza.
Checklist di riconciliazione
- Confronta il numero di sessioni per partner nel CSMS con i CDR inviati e confermati.
- Confronta l'energia totale mensile per partner con il suo estratto.
- Analizza le sessioni con energia zero, durata molto lunga o valori negativi.
- Verifica che ogni CDR di storno faccia riferimento a un originale esistente.
- Concorda con ogni partner un termine e una procedura di contestazione e documentali.
Conservazione e privacy
I CDR contengono dati personali come identificativi dei token e luoghi riconducibili a una persona. Conservali per il tempo richiesto dagli obblighi fiscali e contrattuali, limita gli accessi e applica le regole GDPR a esportazioni e condivisioni con i partner.
Domande frequenti
Chi crea il CDR?
La piattaforma del CPO, perché controlla la colonnina e i dati di misura. L'MSP lo riceve e lo usa per fatturare.
Un MSP può rifiutare un CDR?
Può contestarlo secondo l'accordo di partnership. Tariffe pulite, letture accurate e periodi chiari riducono le contestazioni.
Quanto velocemente va inviato un CDR?
Appena la sessione è finalizzata. I ritardi rallentano la fatturazione dell'MSP e complicano la riconciliazione.
Üreticy crea i CDR dai dati di misura OCPP, applica le tue tariffe e conserva log completi per audit e riconciliazione con i partner. Scopri fatturazione e reportistica oppure contattaci.