ELPO Compliance · Capa de cumplimiento para Turquía
Su CSMS. Listo para Turquía.
Cumplimiento de EPDK y GİB sin reconstruir su plataforma. El Paquete de cumplimiento para Turquía de ELPO es una capa independiente entre el software de su red de recarga (CSMS) y el regulador energético turco EPDK y la administración tributaria GİB. Su CSMS habla el idioma que ya conoce —OCPI— y el paquete se encarga de cada reporte específico de Turquía.
Operar una red de recarga en Turquía no termina con instalar los cargadores
Debe reportar a dos instituciones, en dos formatos distintos y sin demora:
EPDK
Si el conector está libre, si la sesión empezó, si terminó, cuánta energía se entregó, cuál es el precio: cada uno es una llamada aparte con su propio orden y plazo.
GİB
El registro de cada cargador y un informe de ventas firmado con el sello electrónico.
Un CSMS extranjero no sabe nada de esto. El precio de escribir la normativa en su propio código: el software cambia cada vez que cambian las reglas, una versión distinta por país y, lo más traicionero, un reporte que se cae sin que nadie lo note.
La solución: una capa que separa los reportes regulatorios de su software
El Paquete de cumplimiento se sitúa entre su CSMS y el regulador. Su CSMS envía los datos por el flujo estándar de OCPI; el paquete prepara, envía y da seguimiento a los reportes a EPDK y al informe de ventas a GİB. Para un CSMS que no habla OCPI hay una sencilla pasarela REST con cinco eventos.
Ni una sola línea de código específico de Turquía en su CSMS.
Para quién es
Software CSMS y CPO extranjero que entra en Turquía
Cumpla las obligaciones con EPDK y GİB sin escribir código específico de Turquía en su producto.
Operadores locales de redes de recarga con software propio
Cuando cambian las reglas, su software no cambia; el cambio se hace en el paquete.
Resolvemos los reportes regulatorios como una capa independiente que se conecta por protocolo al software de su red de recarga.
Por qué puede confiar en él: lo que se ha medido
Todo lo que sigue funciona hoy en el producto y se ha verificado en el entorno de pruebas.
| Los reportes llegan realmente a EPDK | Aceptaciones con número de registro devueltas por el entorno de pruebas de EPDK |
|---|---|
| Los reportes salen solos, no a mano | La cola se vacía cada 30 segundos; la pantalla muestra la hora del último envío |
| Un reporte fallido no se pierde | Se reintenta a intervalos crecientes; cada intento queda registrado con su contenido y la respuesta del regulador |
| Un reporte rechazado puede corregirse y reenviarse | Una vez corregidos los datos del registro, el elemento vuelve a la cola |
| El mismo reporte nunca se envía dos veces | Cada registro se toma en una única transacción; una segunda pasada no lo toca |
| Una pantalla para cotejar con los registros oficiales de EPDK | Inventario del CSMS a la izquierda, registro de EPDK a la derecha; los registros sin coincidencia destacan |
| Cada red de recarga elige su propia entidad de pago | Se define por titular de licencia |
| También se reportan las sesiones de un CSMS que no puede enviar datos por sí mismo | El paquete lee cada hora las sesiones finalizadas del CSMS conectado; un registro leído así nunca se reporta dos veces |
| El resultado real de cada reporte vuelve al CSMS | El resultado se entrega firmado a la dirección que define el CSMS |
| El CSMS puede volver a leer desde nosotros lo que envió | Funcionan todos los endpoints del lado receptor de OCPI 2.2.1 y 2.3.0: ubicaciones, sesiones, registros de recarga (CDR) y tarifas se envían y se vuelven a leer; cada endpoint se probó uno por uno con una clave real de CSMS |
| El registro de recarga de una estación sin número de EPDK no se pierde | El registro no se rechaza, queda retenido; en cuanto se introduce el número, se envía solo a EPDK y el CSMS no necesita reenviarlo |
| También puede conectarse un CSMS sin OCPI | Una interfaz REST de cinco eventos: sesión iniciada, finalizada, consumo, tarifa, avería |
| El informe de ventas para GİB se genera y se firma cuando hay un sello configurado | Sin sello, el documento se genera igualmente y la pantalla indica que no está firmado |
Las pantallas y lo que demuestran
- Comunicación con EPDK
- Prueba en pantalla de que los reportes salen
- Reporte manual a EPDK
- El operador puede cerrar la brecha entre el terreno y el sistema
- Cotejo del registro
- El paso más crítico de la configuración es visible; un cotejo erróneo no pasa desapercibido
- Conciliación
- Detecta el error de «creía que lo había enviado»
- Informe de ventas para GİB
- Los datos que van al integrador de documentos electrónicos se pueden auditar
- Entidades de pago
- En un negocio con varias redes, cada red conserva su propio acuerdo
- Terminales de pago
- El código QR del conductor nunca lleva a una página vacía
- Configuración
- Un negocio con varias redes se gestiona desde un único panel
Preguntas frecuentes
- ¿Tenemos que cambiar nuestro CSMS?
- No. Si su CSMS habla OCPI, no tiene nada nuevo que aprender; los roles son los mismos que en el flujo estándar CPO→eMSP. Para un CSMS sin OCPI hay una sencilla pasarela REST/webhook.
- ¿Qué pasa cuando cambia la normativa?
- El cambio se hace en el Paquete de cumplimiento; su CSMS no se ve afectado. Esa es precisamente la razón de ser de este producto.
- ¿Sabremos si un reporte falla?
- Sí. Cada intento se registra junto con la respuesta en bruto del regulador. Si la cola se detiene, el indicador en pantalla muestra cuántos minutos lleva sin actividad.
- ¿Dónde se guardan nuestros datos?
- El producto también puede instalarse en sus propios servidores. Las tareas que tocan datos de clientes, como la firma con el sello electrónico, se realizan en sus instalaciones y no se envían al exterior.
- ¿Tenemos que usar SmartŞarj?
- No. El Paquete de cumplimiento funciona con cualquier CSMS; una red de recarga que no use SmartŞarj también puede adquirirlo.