ELPO Compliance · Efterlevnadslager för Turkiet
Ert CSMS. Redo för Turkiet.
EPDK- och GİB-efterlevnad utan att bygga om er plattform. ELPO:s efterlevnadspaket för Turkiet är ett separat lager mellan programvaran för ert laddnätverk (CSMS), Turkiets energitillsynsmyndighet EPDK och skattemyndigheten GİB. Ert CSMS talar det språk det redan kan — OCPI — och paketet tar hand om varje Turkiet-specifik rapport.
Att driva ett laddnätverk i Turkiet slutar inte med att laddarna är installerade
Ni måste rapportera till två myndigheter, i två olika format, utan fördröjning:
EPDK
Är uttaget ledigt, har laddningen startat, har den avslutats, hur mycket energi levererades, vad är priset — varje uppgift är ett eget anrop med egen ordning och tidsgräns.
GİB
Registrering av varje laddare och en försäljningsrapport signerad med elektroniskt sigill.
Ett utländskt CSMS känner inte till något av detta. Priset för att skriva in regelverket i den egna koden: mjukvaran måste ändras varje gång reglerna ändras, en separat version per land och, värst av allt, en tappad rapport som ingen märker.
Lösningen: ett lager som skiljer myndighetsrapporteringen från er mjukvara
Efterlevnadspaketet ligger mellan ert CSMS och tillsynsmyndigheten. CSMS:et skickar data via det vanliga OCPI-flödet; paketet tar fram, skickar och följer upp rapporterna till EPDK och försäljningsrapporten till GİB. För ett CSMS som inte talar OCPI finns en enkel REST-ingång med fem händelser.
Inte en enda rad Turkiet-specifik kod i ert CSMS.
Vem det är för
Utländska CSMS- och CPO-mjukvaror som etablerar sig i Turkiet
Uppfyll kraven från EPDK och GİB utan att skriva Turkiet-specifik kod i er produkt.
Lokala laddnätsoperatörer med egen mjukvara
När reglerna ändras behöver er mjukvara inte ändras; ändringen görs i paketet.
Vi löser myndighetsrapporteringen som ett separat lager som ansluts till programvaran för ert laddnätverk via protokoll.
Därför kan ni lita på det — det här är uppmätt
Allt nedan fungerar i produkten i dag och har verifierats i testmiljön.
| Rapporterna når verkligen EPDK | Mottagningskvitton med registreringsnummer från EPDK:s testmiljö |
|---|---|
| Rapporterna går iväg av sig själva, inte manuellt | Kön töms var 30:e sekund; skärmen visar tiden för senaste sändning |
| En rapport som misslyckas går inte förlorad | Nya försök görs med allt längre intervall; varje försök loggas med innehåll och myndighetens svar |
| En avvisad rapport kan rättas och skickas igen | När registeruppgifterna har rättats läggs posten tillbaka i kön |
| Samma rapport skickas aldrig två gånger | Varje post tas i anspråk i en enda transaktion; en andra körning rör den inte |
| En skärm för avstämning mot EPDK:s officiella register | CSMS-inventariet till vänster, EPDK-registret till höger; poster utan matchning sticker ut |
| Varje laddnätverk väljer sitt eget betalningsinstitut | Anges per licensinnehavare |
| Laddsessioner från ett CSMS som inte kan skicka data rapporteras också | Paketet läser avslutade sessioner från det anslutna CSMS:et varje timme; en post som lästs på det sättet rapporteras aldrig två gånger |
| Det faktiska utfallet av varje rapport går tillbaka till CSMS:et | Resultatet levereras signerat till den adress som CSMS:et anger |
| CSMS:et kan läsa tillbaka från oss det som det skickat | Alla slutpunkter på mottagarsidan i OCPI 2.2.1 och 2.3.0 fungerar: platser, sessioner, laddposter (CDR) och tariffer skickas och läses tillbaka; slutpunkterna har testats en och en med en riktig CSMS-nyckel |
| Laddposten från en station utan EPDK-nummer går inte förlorad | Posten avvisas inte utan hålls kvar; när numret har angetts går den automatiskt till EPDK, och CSMS:et behöver inte skicka den igen |
| Även ett CSMS utan OCPI kan anslutas | Ett REST-gränssnitt med fem händelser: session startad, avslutad, förbrukning, tariff, fel |
| GİB-försäljningsrapporten tas fram och signeras när ett sigill är konfigurerat | Utan sigill tas dokumentet ändå fram och skärmen visar att det är osignerat |
Skärmar och vad de bevisar
- EPDK-kommunikation
- Bevis på skärmen att rapporterna går iväg
- Manuell EPDK-rapportering
- Operatören kan täppa till glappet mellan fält och system
- Registermatchning
- Det mest kritiska installationssteget syns; en felaktig matchning förblir inte tyst
- Avstämning
- Fångar felet ”jag trodde att jag hade skickat den”
- GİB-försäljningsrapport
- Datan som går till e-dokumentintegratören kan granskas
- Betalningsinstitut
- I en verksamhet med flera nätverk behåller varje nätverk sitt eget avtal
- Betalterminaler
- Förarens QR-kod leder aldrig till en tom sida
- Grunddata
- En verksamhet med flera nätverk styrs från en och samma panel
Vanliga frågor
- Måste vi ändra vårt CSMS?
- Nej. Om ert CSMS talar OCPI behöver det inte lära sig något nytt; rollerna är desamma som i det vanliga CPO→eMSP-flödet. För ett CSMS utan OCPI finns en enkel REST/webhook-ingång.
- Vad händer när regelverket ändras?
- Ändringen görs i efterlevnadspaketet; ert CSMS påverkas inte. Det är just därför produkten finns.
- Får vi veta om en rapport misslyckas?
- Ja. Varje försök loggas tillsammans med myndighetens råa svar. Om kön stannar visar indikatorn på skärmen hur många minuter den har varit tyst.
- Var lagras våra data?
- Produkten kan även installeras på era egna servrar. Arbete som berör kunddata, till exempel signering med elektroniskt sigill, utförs på plats och skickas inte ut.
- Måste vi använda SmartŞarj?
- Nej. Efterlevnadspaketet fungerar med alla CSMS; även ett laddnätverk som inte använder SmartŞarj kan köpa det.