chargecloud.de um eine Dienstwagen-Abrechnung zu ermöglichen

[ChristophR]

Ich dachte nur an die Info mit wem ihr das entwickelt habt. (Falls es einen gibt)

OCPP steckt dahinter.

Ja, das ist das Protokoll.
Ich hatte es bisher so verstanden, dass dann auch die komplette Steuerung der Wallbox über OCPP erfolgt.
Wir wollen aber die Steuerung bei openWB belassen, wäre ja sonst langweilig.
Wenn es jetzt so umgesetzt ist, dass quasi nur die Ladeprotokolle bestimmter Fahrzeuge darüber abgerufen werden können, entspricht das ja ggf. nicht der Idee, die die Ladeabrechnungsanbieter haben.
Daher dachte ich, ihr hättet das bereits mit einem Anbieter zusammen umgesetzt, das wäre ja für beide ein Verkaufsargument. (z.B. die klassische Win-Win Situation einer Partnerschaft)

Ich schließe nun daraus, dass es auf Seite der openWB nach Protokollstandard umgesetzt wurde und relativ unklar ist, mit welchem Anbieter man das nutzen kann.
Das wäre quasi deren Baustelle, den Standard auch nutzen zu können / wollen?

Vielleicht habe ich das ja auch falsch verstanden, dann kann mich gerne jemand schlauer machen...

[Gero]

Normale OCPP-Ladepunkte werden vom Server des Anbrechnungsanbieter wie ein öffentlicher Ladepunkt gesteuert: nach Authentifikation wird der Ladevorgang freigeschaltet und nach Ende werden die Ladadaten zurückübermittelt. Der Anbieter macht dann einmal monatlich eine Abrechnung und verteilt das eingenommene Geld. Viele dieser Abrechensysteme nehmen auch OCPP als Protokoll, letzten Endes kommt es sogar auch genau da her.

Nun gibt es Dienstwagen mit „Sprit inklusive“. Damit nun die Buchhaltung nicht jeden Tankbeleg einzeln eintippen muss, gibt es Tankkarten, die z.B. bei DKV auch Ladekarten sind. Oder zwei Karten gehen in einen Account. So muss die Buchhaltung nur eine Monatsabrechnung buchen.

Nun gibt es Strom - im Gegensatz zu Benzin oder Diesel - auch an der heimischen Steckdose und da stellt sich nun die Frage nach der Abrechnung, damit der Dienstwagennehmer auch den Komfort eines morgens vollgeladenen Autos genießen kann. Den Zählerstand einmal jährlich abzulesen, erscheint zu einfach und nicht betrugssicher genug. Ladeprotokolle in einem Excel sind das zwar auch nicht, erwecken aber des Deaillierungsgrads wegen zumindest mal den Eindruck. Sie haben allerdings den Nachteil, dass man sie irgendwie eintippen muss. Das versprechen die OCPP-Dienstwagen-Wallboxen mit ihren Abrechnungsprovidern im Hintergrund zu automatisieren. Diese Daten werden sicherlich auch nur in den seltensten Fällen per EDI oder ähnlichem in die Buchhaltung übertragen und fälschungssicher ist das auch nicht, nur ist die Komplexität an dieser Stelle so hoch, dass man a) die Sicherheit vorgaukeln und b) richitg Geld dafür nehmen kann. Insbesondere, wenn man als Ladekartenabrechnungssystem auch noch ins Wallboxgeschäft mit einsteigen kann.

Ende des Vorgeplänkels für das „Warum“

Nun gibt es ja durchaus den einen oder anderen, der schon eine openWB betreibt und sich nun fragt, wie er seinen Dienstwagenstrom, der mittlerweile elektrisch ist, abrechnen kann. Und da kommt man immer wieder bei OCPP vorbei. Und die openWB kann das nicht. So richtig mit authentifizierung braucht man das ja auch nicht, da an der heimischen Wallbox meist immer nur ein Auto lädt. Und es geht ja letzten Endes nur darum, die Ladelogeinträge an irgend einen OCPP-Server zu verteilen, damit von da aus der Abrechnungswahnsinn seinen Lauf nehmen kann…siehe oben.

Es gibt wirklich Firmen, die ihren Mitarbeitern eine Keba oder so in die Garage hängen, damit der Strom so richtig schön perfekt abgerechnet werden kann.

Um diesem Wahnsinn nun ein Ende zu setzen, wird nun OCPP 1.6 implementiert. So kann dann jeder openWB-Besitzer seine Ladelogs an einen Abrechner verteilen und braucht sich keine Keba oder so extra in die Garage hängen oder große Diskussionen zu führen, ob eine kommunizierte Zahl am Jahresende auch reichen könnte.

[openWB]

Jepp, mit dem unterschied das wir nicht 100% OCPP konform sind was die Authentifizierung angeht.
Sagt das Backend „darf nicht laden weil kenn ich nicht“ ignorieren wir das, teilen dem backend aber fleißig alle Ladungen mit.
Somit ist gewährleistet das die Steuerungshoheit bei openWB bleibt aber jemand anderes die Ladungen mitbekommt.
Mit der openWB Pro und Fahrzeugerkennung geht das dann auch komplett automatisch.

Sehe es mal runtergebrochen als einen sehr komplizierten Weg an das openWB ladelog jemandem zu geben.

Sicherlich werden wir mit einigen Tests durchführen und auch von der Community wird es Feedback geben.

Gero hat das aber schon gut zusammen gefasst, bei manchen ist da nochmal ein geeichter Zähler involviert was das ganze eigentlich absurdum führt. „Sicher“ ist der ganze OCPP Krempel wie er in D implementiert ist übrigens garnicht, aber auch das ist seit Jahren bekannt. Sieht auf dem Papier aber schön aus.

[ChristophR]

Dann deckt sich das quasi mit meinem Kenntnisstand, Danke Gero.

Stellt sich nur noch die Frage, ob es bereits Ladeabrechnungsanbieter gibt, die Lust darauf haben, auf das "Zusatzgeschäft" mit dem Verkauf von Wallboxen zu verzichten und tatsächlich reine OCPP-Ladeprotokolle (Von der openWB) akzeptieren. Das war meine Zusatzfrage, ob hierzu bereits Erkenntnisse vorliegen.
Ein Problem könnte z.B. werden, wenn die nur ihre eigenen RFID Karten zur Autorisierung akzeptieren, dass wir dann einen 13,54MHz RFID-Leser brauchen. (Den habe ich bei mir sowieso schon nachgerüstet, daher kann ich bestätigen, dass das funktionieren kann)

Ich lade bei mir tatsächlich auch z.T. ein anderes Fahrzeug, so dass der Zählerstand alleine nicht zur Abrechnung genommen werden kann.
Mein AG akzeptiert die Excel-Ladeprotokolle aus der openWB, durch die täglichen Backups könnte ich den Anschein der Nichtmanipulation auch festigen.
Wenn aber irgendwann das Finanzamt oder ein Steuerprüfer daran rummäkeln möchte, wäre die Anbindung über solch einen Abrechnungsanbieter ggf. für beide Seiten sicherer.
Daher interessiere ich mich für das Thema, könnte in der Form ja auch auf andere zutreffen.

EDIT: Die Antwort von openWB habe ich erst nach meinem Post gesehen, lasse es aber trotzdem stehen. Danke für die Rückmeldungen.

[Gero]

Wenn aber irgendwann das Finanzamt oder ein Steuerprüfer daran rummäkeln möchte, wäre die Anbindung über solch einen Abrechnungsanbieter ggf. für beide Seiten sicherer.

Ja, es ist irgendwie erschreckend, wie sich der Glaube gefestigt hat, dass wenn nur genügend Parteien in so einem jeder-schlägt-ein-bisschen-drauf Abrechnungsringelpietz mitmachen, dass das irgendwie authentischer, zuverlässiger, betrugssicher oder noch aus irgendwelchen anderen Gründen besser werden soll. Das Gegenteil ist eigentlich der Fall: wenn man Rechnungen durch mehrere (möglichst viele) Buchhaltungen durchreicht - am Besten noch über Ländergrenzen hinweg - dann ist eigentlich die Gefahr einer Steuerhinterziehung viel größer. (Google-Stichwort umsatzsteuerkarussel)

Naja, aber letzten Endes leben wir alle sehr gut vom irre gewordenen Verwaltungsseppel
oder dem mehr und mehr um sich greifenden Compliance-Kram

[zone27]

Gibt es ein ungefähres Datum bis wann die OCPP Backend Funktion in welcher 2.x Version verfügbar sein wird?

[LutzB]

Ist für 2.1.6 geplant.

[zone27]

Danke für die Info. Gibt es für das Release der 2.1.6 schon ein ungefähres Datum?

[kurzschluss_meister]

Mal ein ganz anderer Gedankengang.

Solange sich der AG / Ladeanbieter, z.B. DKV querstellt: Könnte man nicht eine WB hinter eine andere hängen?

Das heißt 1. WB ist die von DKV. Bei ihr wird nur am CP "simuliert" dass ein Auto daran hängt, dass gerne Strom haben möchte. Danhinter hängt an den 3 Phasen aber die Phasenumschaltung der openWB. und auch am openWB CP Signal ist das eigentliche Auto angeschlossen.

Einzige Komplexität, in der OpenWB müsste die Stromversorgung L1 der Steuerung von dem L2 der von der DKV box kommt getrennt werden, sodass die Steuerungselektronik dauerhaft Strom hat.

Nur ein Gedankengang von mir... da ich mir nicht vorstellen kann, das DKV langfristig fremdwollboxen per OCPP in ihr System aufnimmt. Den Support möchten sie bestimmt nicht leisten...