ELPO Compliance · Türkei-Compliance-Schicht
Ihr CSMS. Bereit für die Türkei.
EPDK- und GİB-Konformität, ohne Ihre Plattform neu zu bauen. Das ELPO Türkei-Compliance-Paket ist eine eigene Schicht zwischen Ihrer Ladenetz-Software (CSMS), der türkischen Energiemarktaufsicht EPDK und der Finanzverwaltung GİB. Ihr CSMS spricht die Sprache, die es kennt — OCPI —, und jede türkeispezifische Meldung übernimmt das Paket.
Ein Ladenetz in der Türkei zu betreiben, endet nicht mit der Installation der Ladesäulen
Sie müssen zwei Behörden in zwei verschiedenen Formaten und ohne Verzögerung melden:
EPDK
Ist der Anschluss frei, hat der Ladevorgang begonnen, ist er beendet, wie viel Energie wurde geliefert, wie hoch ist der Preis — jeweils ein eigener Aufruf mit eigener Reihenfolge und Frist.
GİB
Registrierung jeder Ladesäule und ein mit dem elektronischen Finanzsiegel signierter Verkaufsbericht.
Ein ausländisches CSMS kennt nichts davon. Der Preis, die Vorschriften in den eigenen Code zu schreiben: Die Software ändert sich mit jeder Regeländerung, eine eigene Version pro Land und, am heimtückischsten, eine verlorene Meldung, die niemand bemerkt.
Die Lösung: eine Schicht, die Behördenmeldungen von Ihrer Software trennt
Das Compliance-Paket sitzt zwischen CSMS und Behörde. Das CSMS sendet Daten über den Standard-OCPI-Ablauf; Meldungen an die EPDK und den Verkaufsbericht an die GİB erstellt, sendet und verfolgt das Paket. Für ein CSMS ohne OCPI gibt es eine schlanke REST-Schnittstelle mit fünf Ereignissen.
Keine einzige Zeile türkeispezifischer Code in Ihrem CSMS.
Für wen
Ausländische CSMS- und CPO-Software mit Markteintritt in der Türkei
EPDK- und GİB-Pflichten erfüllen, ohne türkeispezifischen Code in Ihr Produkt zu schreiben.
Türkische Ladenetzbetreiber mit eigener Software
Ändern sich die Regeln, ändert sich nicht Ihre Software — die Änderung erfolgt im Paket.
Wir lösen Behördenmeldungen als eigene Schicht, die sich per Protokoll an Ihre Ladenetz-Software anbindet.
Warum Sie sich darauf verlassen können — was gemessen wurde
Alles Folgende läuft heute im Produkt und wurde in der Testumgebung geprüft.
| Meldungen erreichen die EPDK wirklich | Annahmebestätigungen mit Registriernummer aus der EPDK-Testumgebung |
|---|---|
| Meldungen gehen von selbst raus, nicht von Hand | Die Warteschlange wird alle 30 Sekunden geleert; der Bildschirm zeigt die Zeit der letzten Sendung |
| Eine fehlgeschlagene Meldung geht nicht verloren | Wiederholung in wachsenden Abständen; jeder Versuch wird mit Inhalt und Antwort der Behörde protokolliert |
| Eine abgelehnte Meldung lässt sich korrigieren und erneut senden | Nach Korrektur der Registerdaten geht der Datensatz zurück in die Warteschlange |
| Dieselbe Meldung geht nie zweimal raus | Jeder Datensatz wird in einer einzigen Transaktion übernommen; ein zweiter Durchlauf rührt ihn nicht an |
| Abgleich mit dem amtlichen EPDK-Register | Links das CSMS-Inventar, rechts das EPDK-Register; Abweichungen werden hervorgehoben |
| Jedes Ladenetz wählt seinen eigenen Zahlungsdienstleister | Festlegung je Lizenzinhaber |
| Auch Ladevorgänge eines CSMS ohne Push-Funktion werden gemeldet | Das Paket liest stündlich beendete Ladevorgänge aus dem verbundenen CSMS; ein so gelesener Datensatz wird nie doppelt gemeldet |
| Das echte Ergebnis jeder Meldung geht zurück an das CSMS | Das Ergebnis wird signiert an die vom CSMS festgelegte Adresse übermittelt |
| Das CSMS kann bei uns zurücklesen, was es gesendet hat | Alle Endpunkte der Empfängerseite von OCPI 2.2.1 und 2.3.0 funktionieren: Standorte, Ladevorgänge, Ladedatensätze (CDR) und Tarife werden gesendet und zurückgelesen; jeder Endpunkt wurde einzeln mit einem echten CSMS-Schlüssel getestet |
| Der Ladedatensatz einer Station ohne EPDK-Nummer geht nicht verloren | Der Datensatz wird nicht abgelehnt, sondern zurückgehalten; sobald die Nummer eingetragen ist, geht er von selbst an die EPDK, ohne dass das CSMS ihn erneut senden muss |
| Auch ein CSMS ohne OCPI kann sich anbinden | REST-Schnittstelle mit fünf Ereignissen: Start, Ende, Verbrauch, Tarif, Störung |
| Der GİB-Verkaufsbericht wird erstellt und bei hinterlegtem Siegel signiert | Ohne Siegel wird das Dokument trotzdem erstellt; der Bildschirm weist es als unsigniert aus |
Bildschirme und was sie belegen
- EPDK-Kommunikation
- Der Versand ist auf dem Bildschirm belegt
- Manuelle EPDK-Meldung
- Der Betreiber schließt die Lücke zwischen Standort und System
- Registerabgleich
- Der wichtigste Einrichtungsschritt ist sichtbar; eine falsche Zuordnung bleibt nicht unbemerkt
- Abstimmung
- Fängt den Fehler „Ich dachte, ich hätte es gesendet“
- GİB-Verkaufsbericht
- Die Daten an den E-Beleg-Integrator sind prüfbar
- Zahlungsdienstleister
- Im Mehrnetzbetrieb behält jedes Netz seinen eigenen Vertrag
- Bezahlterminals
- Der QR-Code des Fahrers führt nie ins Leere
- Stammdaten
- Ein Mehrnetzbetrieb wird über eine Oberfläche geführt
Häufige Fragen
- Müssen wir unser CSMS ändern?
- Nein. Spricht Ihr CSMS OCPI, muss es nichts Neues lernen; die Rollenverteilung entspricht dem Standardablauf CPO→eMSP. Für ein CSMS ohne OCPI gibt es eine einfache REST-/Webhook-Schnittstelle.
- Was passiert, wenn sich die Vorschriften ändern?
- Die Änderung erfolgt im Compliance-Paket; Ihr CSMS ist nicht betroffen. Genau dafür gibt es dieses Produkt.
- Erfahren wir, wenn eine Meldung scheitert?
- Ja. Jeder Versuch wird mit der Rohantwort der Behörde protokolliert. Steht die Warteschlange, zeigt die Anzeige, seit wie vielen Minuten sie still ist.
- Wo liegen unsere Daten?
- Das Produkt lässt sich auch auf Ihren eigenen Servern installieren. Arbeiten mit Kundendaten, etwa die Signatur mit dem Finanzsiegel, erfolgen vor Ort und werden nicht nach außen gesendet.
- Müssen wir SmartŞarj nutzen?
- Nein. Das Compliance-Paket arbeitet mit jedem CSMS; auch ein Ladenetz ohne SmartŞarj kann es kaufen.