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

Part of the lesson OCPI charging session lifecycle

CPO sends the CDR for billing

Start here
8 min
OCPI 2.1.1, 2.2.1 and 2.3.0Test this flow runs against an eMSP endpoint you have registered. The endpoint test grades your endpoint's answer to each Session push. It does not read the stored Session back.
Test this flow
CPO sends the CDR for billing

The CPO creates the billing-relevant CDR after the charge and sends it to the eMSP. The excerpt shows cost and charging-period information.

Sandbox run · OCPI 2.2.1

Run this exchange in the sandbox

CPO
EMSP
"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
Explore the cdrs module →
Message Flow⚡UUserCChargerCCPOsendereeMSPreceiverStep 9 of 10