Learning Hub/Scenarios
Explanations use OCPI 2.2.1. Physical and billing-system events are authored examples.

A retry creates a second CDR ID

Advanced
4 min
OCPI 2.1.1, 2.2.1 and 2.3.0
CPO POSTs the CDR and the eMSP stores it
A retry creates a second CDR ID

In this authored example the connection drops before the CPO sees the answer, and its billing system sends the same visit again under a new CDR id, CDR-NL-GCH-88402. The eMSP stores two CDRs and bills the customer twice.

This outcome is written for the lesson. A sandbox run cannot produce it.

CPO
EMSP
Authored observation

One charge is now billed twice, because a retry created a second CDR instead of re-sending the first.

The duplicate customer charge is an authored billing-system observation, not a rule that every second CDR for a Session must fail. Sent CDRs cannot be changed or deleted. To correct a sent CDR, send a Credit CDR with a different ID, credit = true, credit_reference_id naming the original and negative original total_cost. A fresh corrected CDR may follow. In the reading ChargerDojo uses, which the spec does not settle, re-sending the same CDR with the same owner, id and content is a retry the receiver accepts; different content under the same owner and id is the change the spec forbids.

"A *Charge Detail Record* is the description of a concluded charging session. The CDR is the only billing-relevant object. CDRs are sent from the CPO to the eMSP after the charging session has ended. Although there is no requirement to send CDRs in (semi-) realtime, it is seen as good practice to send them as soon as possible. But if there is an agreement between parties to send them, for example, once a month, that is also allowed by OCPI."OCPI 2.2.1 CDRs module · #mod_cdrs_cdrs_module"CDRs are created by the CPO. They most likely will be sent only to the eMSP that needs to pay the bill of the underlying charging session. Because a CDR is for billing purposes, it cannot be changed or replaced once sent to the eMSP. Changes are simply not allowed. Instead, a Credit CDR can be sent. CDRs may be sent for charging locations that have not been published via the Location module. This is typically for home chargers."OCPI 2.2.1 CDRs module · #mod_cdrs_flow_and_lifecycle"As CDRs are used for billing and can be seen as a kind of invoice, they cannot be deleted. Instead, they have to be credited. When a CPO wants to make changes to a CDR that was already sent to the eMSP, the CPO has to send a Credit CDR for the first CDR. This credit CDR SHALL have a different CDR.id which can be a completely different number, or it can be the id of the original CDR with something appended like for example: `-C` to make it unique again. To indicate that a CDR is a Credit CDR, the `credit` field has to be set to `true`. The Credit CDR references the old CDR via the `credit_reference_id` field, which SHALL contain the `id` of the original CDR. The Credit CDR will contain all the data of the original CDR. Only the values in the `total_cost` field SHALL contain the negative amounts of the original CDR. After having sent the Credit CDR, the CPO can send a new CDR with a new unique ID and the fields: `credit` and `credit_reference_id` omitted."OCPI 2.2.1 CDRs module · #mod_cdrs_credit_cdrs
Explore the cdrs module →
Previous
Message Flow!CCPOsendereeMSPreceiverUUserStep 2 of 2