Chaque session de recharge payante se termine par un document qui détermine qui paie qui, et combien : le CDR, ou Charge Detail Record. Le conducteur ne le voit jamais, mais factures, règlements d'itinérance, déclarations fiscales et litiges en dépendent. Des CDR erronés font perdre de l'argent discrètement et abîment les relations avec les partenaires.

Ce guide détaille le contenu d'un CDR, sa construction par un CSMS à partir des données OCPP et son rapprochement avec les partenaires.

À retenir
  • Un CDR est l'enregistrement définitif et immuable d'une session terminée.
  • Il est construit à partir des données de transaction et de comptage OCPP et du tarif applicable.
  • Un CDR envoyé n'est jamais modifié ; les corrections passent par des CDR d'avoir.
  • Un rapprochement mensuel avec vos propres données évite les pertes de revenus silencieuses.

Ce qu'est un CDR

Un CDR décrit une session une fois terminée : qui a rechargé, où, quand, quelle énergie a été délivrée, quels prix s'appliquaient et quel est le coût total. En itinérance, le CPO envoie ses CDR à l'eMSP, qui facture son conducteur et paie le CPO. En interne, le même enregistrement sert de base à vos factures et rapports. Son équivalent en direct pendant la charge est l'objet session, présenté dans notre guide des modules OCPI 2.2.1.

Les champs clés d'un CDR OCPI

ChampContenu
idIdentifiant unique du CDR attribué par le CPO
start_date_time / end_date_timeDébut et fin de session en UTC
session_idLien vers la session correspondante
cdr_tokenJeton utilisé : UID RFID, jeton d'application et identifiant de contrat
auth_methodMode d'autorisation, par exemple liste blanche ou temps réel
cdr_locationAdresse, coordonnées, identifiant EVSE et connecteur au moment de la charge
currency et tariffsDevise et tarifs appliqués
charging_periodsBlocs de temps avec dimensions énergie, durée et stationnement
signed_dataValeurs de compteur signées facultatives pour vérification
total_cost, total_energy, total_time, total_parking_timeTotaux servant à la facturation
credit, credit_reference_idSignale un CDR d'avoir et le relie à l'original

Comment un CSMS construit un CDR à partir d'OCPP

  1. Démarrage : la borne envoie StartTransaction (OCPP 1.6J) ou un TransactionEvent de type Started (OCPP 2.0.1) avec l'index de départ et l'identifiant autorisé.
  2. Pendant la charge : les MeterValues remontent énergie, puissance et parfois état de charge à intervalles configurés.
  3. Arrêt : StopTransaction ou TransactionEvent Ended fournit l'index final, le motif d'arrêt et, si configuré, des données de transaction.
  4. Tarification : le CSMS applique le tarif en vigueur au démarrage à l'énergie, à la durée et au temps d'occupation.
  5. Finalisation : le CDR est créé, stocké, puis envoyé aux partenaires ou utilisé pour facturer.

Le flux de messages est décrit dans notre article sur StartTransaction et StopTransaction.

Les périodes de charge, ce détail qui compte

Un CDR n'est pas qu'un total. Les périodes de charge découpent la session dès qu'une dimension tarifaire change, par exemple à la fin d'une plage horaire ou quand la voiture a fini de charger mais reste branchée. Les partenaires s'en servent pour recalculer le prix. Si vos périodes ne correspondent pas au tarif publié, l'eMSP ne peut pas vérifier votre total et le conteste.

CDR d'avoir et corrections

Un CDR envoyé est définitif. En cas d'erreur, comme un défaut de comptage ou un tarif mal appliqué, vous envoyez un CDR d'avoir qui annule l'original, puis un nouveau CDR correct. Les deux parties conservent ainsi une piste d'audit. Ne modifiez jamais discrètement des totaux dans votre base sans avoir correspondant.

Valeurs de compteur signées

Sur les marchés aux règles de métrologie strictes, les bornes peuvent signer leurs relevés pour que le conducteur ou un tiers vérifie que les valeurs n'ont pas été altérées. Ces valeurs signées peuvent figurer dans le champ signed_data du CDR. Le compteur et le firmware doivent prendre en charge la signature : vérifiez la réglementation locale et votre matériel.

Causes fréquentes de CDR erronés

  • Arrêts de transaction manquants après un redémarrage ou une perte de connexion, laissant des sessions ouvertes.
  • Index de compteur qui sautent ou repartent à zéro après une mise à jour du firmware.
  • Dérive d'horloge de la borne, faussant horaires et tarification par plage.
  • Changements de tarif appliqués à des sessions commencées avant le changement.
  • Frais d'occupation calculés sur la durée de branchement au lieu de la fin de charge, voir frais d'occupation.
  • CDR en double après des relances sans contrôle d'idempotence.

Check-list de rapprochement

  1. Comparer le nombre de sessions par partenaire dans le CSMS aux CDR envoyés et acquittés.
  2. Comparer l'énergie totale mensuelle par partenaire avec son relevé.
  3. Analyser les sessions à énergie nulle, très longues ou à valeurs négatives.
  4. Vérifier que chaque CDR d'avoir référence un original existant.
  5. Convenir avec chaque partenaire d'un délai et d'une procédure de contestation, et les documenter.

Conservation et confidentialité

Les CDR contiennent des données personnelles, comme des identifiants de jeton et des lieux rattachables à une personne. Conservez-les aussi longtemps que l'exigent vos obligations fiscales et contractuelles, limitez les accès et appliquez vos règles RGPD aux exports et aux échanges avec les partenaires.

Questions fréquentes

Qui crée le CDR ?

La plateforme du CPO, car elle contrôle la borne et les données de comptage. L'eMSP le reçoit et l'utilise pour facturer.

Un eMSP peut-il refuser un CDR ?

Il peut le contester dans le cadre de l'accord de partenariat. Des tarifs propres, des relevés exacts et des périodes claires limitent les litiges.

Dans quel délai envoyer un CDR ?

Dès que la session est finalisée. Les retards décalent la facturation de l'eMSP et compliquent le rapprochement.

Üreticy génère les CDR à partir des relevés OCPP, applique vos tarifs et conserve des journaux complets pour les audits et le rapprochement. Voir les fonctions de facturation et de reporting ou contactez-nous.