Explanations use OCPI 2.2.1. Physical and billing-system events are authored examples.
No closing Session update or CDR arrives
Advanced
5 min
No closing Session update or CDR arrivesExplore the sessions module →
The eMSP has received neither a closing Session update nor a CDR. Its stored Session is still ACTIVE at 18.4 kWh, the last state it observed, so the operator investigates the missing messages.
This outcome is written for the lesson. A sandbox run cannot produce it.
CPO
EMSP
Authored observation
The eMSP has not received the closing Session update or CDR in this example.
In the Session push model the final status is COMPLETED. Until the CPO sends it, the copy the eMSP holds stays ACTIVE: the evidence is incomplete, and the gap is an observation to reconcile rather than a protocol result. CDR delivery may be delayed by agreement, including monthly delivery.
"When the CPO creates a Session object they push it to the corresponding eMSP by calling PUT on the eMSP's Sessions endpoint with the newly created Session object. Any changes to a Session in the CPO system are sent to the eMSP system by calling PATCH on the eMSP's Sessions endpoint with the updated Session object. Sessions cannot be deleted, final status of a session is: `COMPLETED`. When the CPO is not sure about the state or existence of a Session object in the eMSP's system, the CPO can call GET on the eMSP's Sessions endpoint to validate the Session object in the eMSP's system."OCPI 2.2.1 Sessions module · #mod_sessions_push_model"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
Message FlowStep 4 of 4