ELPO Compliance · Warstwa zgodności dla Turcji
Twój CSMS. Gotowy na Turcję.
Zgodność z EPDK i GİB bez przebudowy platformy. Pakiet zgodności ELPO dla Turcji to osobna warstwa między oprogramowaniem Twojej sieci ładowania (CSMS) a tureckim regulatorem rynku energii EPDK i administracją skarbową GİB. Twój CSMS mówi językiem, który już zna — OCPI — a pakiet przejmuje każde raportowanie specyficzne dla Turcji.
Prowadzenie sieci ładowania w Turcji nie kończy się na montażu ładowarek
Musisz raportować do dwóch instytucji, w dwóch różnych formatach i bez opóźnień:
EPDK
Czy złącze jest wolne, czy sesja się rozpoczęła, czy się zakończyła, ile energii dostarczono, jaka jest cena — każde to osobne wywołanie z własną kolejnością i terminem.
GİB
Rejestracja każdej ładowarki oraz raport sprzedaży podpisany elektroniczną pieczęcią skarbową.
Zagraniczny CSMS nie wie nic z tych rzeczy. Cena wpisania przepisów we własny kod: oprogramowanie zmienia się przy każdej zmianie regulacji, osobna wersja dla każdego kraju i — co najgorsze — zgubiony raport, którego nikt nie zauważa.
Rozwiązanie: warstwa, która oddziela raportowanie regulacyjne od Twojego oprogramowania
Pakiet zgodności działa pomiędzy Twoim CSMS a regulatorem. CSMS przesyła dane standardowym przepływem OCPI; pakiet przygotowuje, wysyła i monitoruje raporty do EPDK oraz raport sprzedaży do GİB. Dla CSMS, który nie obsługuje OCPI, dostępna jest prosta bramka REST z pięcioma zdarzeniami.
Ani jednej linii kodu specyficznego dla Turcji w Twoim CSMS.
Dla kogo
Zagraniczne oprogramowanie CSMS i CPO wchodzące do Turcji
Spełnij obowiązki wobec EPDK i GİB bez pisania kodu specyficznego dla Turcji w swoim produkcie.
Lokalni operatorzy sieci ładowania z własnym oprogramowaniem
Gdy zmieniają się przepisy, Twoje oprogramowanie się nie zmienia; zmianę wprowadza się w pakiecie.
Rozwiązujemy raportowanie regulacyjne jako osobną warstwę, która łączy się z oprogramowaniem Twojej sieci ładowania za pomocą protokołu.
Dlaczego możesz na tym polegać — co zostało zmierzone
Wszystko poniżej działa dziś w produkcie i zostało zweryfikowane w środowisku testowym.
| Raporty naprawdę docierają do EPDK | Potwierdzenia przyjęcia z numerem rejestracyjnym ze środowiska testowego EPDK |
|---|---|
| Raporty wychodzą same, nie ręcznie | Kolejka jest opróżniana co 30 sekund; ekran pokazuje godzinę ostatniej wysyłki |
| Raport, którego nie udało się wysłać, nie ginie | Ponawiany w rosnących odstępach; każda próba jest zapisywana wraz z treścią i odpowiedzią regulatora |
| Odrzucony raport można poprawić i wysłać ponownie | Po korekcie danych rejestrowych rekord wraca do kolejki |
| Ten sam raport nigdy nie zostaje wysłany dwa razy | Każdy rekord jest przejmowany w jednej transakcji; drugi przebieg go nie dotyka |
| Ekran uzgadniania z oficjalnym rejestrem EPDK | Po lewej inwentarz CSMS, po prawej rejestr EPDK; niedopasowane rekordy są wyróżnione |
| Każda sieć ładowania wybiera własną instytucję płatniczą | Definiowane dla każdego posiadacza koncesji |
| Sesje z CSMS, który nie potrafi wysyłać danych, też są raportowane | Pakiet co godzinę sam odczytuje zakończone sesje z podłączonego CSMS; tak odczytany rekord nigdy nie jest raportowany dwukrotnie |
| Rzeczywisty wynik każdego raportu wraca do CSMS | Wynik jest przekazywany, podpisany, na adres wskazany przez CSMS |
| CSMS może odczytać od nas z powrotem to, co wysłał | Działają wszystkie punkty końcowe po stronie odbiorcy w OCPI 2.2.1 i 2.3.0: lokalizacje, sesje, rekordy ładowania (CDR) i taryfy są wysyłane i odczytywane z powrotem; punkty końcowe przetestowano jeden po drugim z prawdziwym kluczem CSMS |
| Rekord ładowania ze stacji bez numeru EPDK nie ginie | Rekord nie jest odrzucany, lecz wstrzymywany; po wpisaniu numeru sam trafia do EPDK, a CSMS nie musi go wysyłać ponownie |
| Również CSMS bez OCPI może się podłączyć | Interfejs REST z pięcioma zdarzeniami: rozpoczęcie sesji, zakończenie, zużycie, taryfa, awaria |
| Raport sprzedaży GİB jest generowany i podpisywany, gdy skonfigurowano pieczęć | Bez pieczęci dokument i tak powstaje, a ekran informuje, że jest niepodpisany |
Ekrany i to, czego dowodzą
- Komunikacja z EPDK
- Dowód na ekranie, że raporty wychodzą
- Ręczne raportowanie do EPDK
- Operator zamyka lukę między lokalizacją a systemem
- Dopasowanie rejestru
- Najważniejszy krok konfiguracji jest widoczny; błędne dopasowanie nie przejdzie niezauważone
- Uzgadnianie
- Wyłapuje błąd „myślałem, że to wysłałem”
- Raport sprzedaży GİB
- Dane trafiające do integratora e-dokumentów można audytować
- Instytucje płatnicze
- W firmie z wieloma sieciami każda sieć zachowuje własną umowę
- Terminale płatnicze
- Kod QR kierowcy nigdy nie prowadzi do pustej strony
- Definicje
- Firma z wieloma sieciami zarządzana jest z jednego panelu
Najczęstsze pytania
- Czy musimy zmieniać nasz CSMS?
- Nie. Jeśli Twój CSMS obsługuje OCPI, nie musi uczyć się niczego nowego; podział ról jest taki sam jak w standardowym przepływie CPO→eMSP. Dla CSMS bez OCPI dostępna jest prosta bramka REST/webhook.
- Co się stanie, gdy zmienią się przepisy?
- Zmianę wprowadza się w Pakiecie zgodności; Twój CSMS pozostaje nietknięty. Właśnie po to istnieje ten produkt.
- Czy dowiemy się, gdy raport nie dotrze?
- Tak. Każda próba jest zapisywana wraz z surową odpowiedzią regulatora. Jeśli kolejka stanie, wskaźnik na ekranie pokaże, od ilu minut milczy.
- Gdzie przechowywane są nasze dane?
- Produkt można zainstalować również na własnych serwerach. Operacje dotykające danych klientów, takie jak podpisywanie elektroniczną pieczęcią, wykonywane są na miejscu i nie są wysyłane na zewnątrz.
- Czy musimy korzystać ze SmartŞarj?
- Nie. Pakiet zgodności działa z każdym CSMS; może go kupić także sieć ładowania, która nie korzysta ze SmartŞarj.