ELPO Compliance · Camada de Conformidade Turquia
Seu CSMS. Pronto para a Turquia.
Conformidade com EPDK e GİB sem reconstruir sua plataforma. O Pacote de Conformidade Turquia da ELPO é uma camada independente entre o software da sua rede de recarga (CSMS) e os órgãos turcos EPDK, regulador de energia, e GİB, administração tributária. Seu CSMS fala a língua que já conhece — OCPI — e o pacote assume todos os reportes específicos da Turquia.
Operar uma rede de recarga na Turquia não termina na instalação dos carregadores
Você precisa reportar a duas instituições, em dois formatos diferentes, sem atraso:
EPDK
O conector está disponível, a sessão começou, terminou, quanta energia foi entregue, qual é o preço — cada item é uma chamada separada, com ordem e prazo próprios.
GİB
Registro de cada carregador e um relatório de vendas assinado com o selo eletrônico fiscal.
Um CSMS estrangeiro não conhece nada disso. O preço de escrever a regulação no próprio código: o software muda a cada mudança de regra, uma versão separada por país e, o pior de tudo, um reporte perdido que ninguém percebe.
A solução: uma camada que separa o reporte regulatório do seu software
O Pacote de Conformidade fica entre o seu CSMS e o regulador. Seu CSMS envia os dados pelo fluxo padrão OCPI; o pacote prepara, envia e acompanha os reportes à EPDK e o relatório de vendas ao GİB. Para um CSMS que não fala OCPI, há um gateway REST simples com cinco eventos.
Nem uma única linha de código específico da Turquia no seu CSMS.
Para quem
Softwares estrangeiros de CSMS e CPO que estão entrando na Turquia
Cumpra as obrigações com a EPDK e o GİB sem escrever código específico da Turquia no seu produto.
Operadores locais de redes de recarga com software próprio
Quando as regras mudam, seu software não muda; a alteração é feita no pacote.
Resolvemos o reporte regulatório como uma camada independente que se conecta ao software da sua rede de recarga por protocolo.
Por que você pode confiar — o que foi medido
Tudo abaixo funciona hoje no produto e foi verificado no ambiente de testes.
| Os reportes realmente chegam à EPDK | Confirmações com número de registro retornadas pelo ambiente de testes da EPDK |
|---|---|
| Os reportes saem sozinhos, não à mão | A fila é esvaziada a cada 30 segundos; a tela mostra o horário do último envio |
| Um reporte que falha não se perde | Novas tentativas em intervalos crescentes; cada tentativa é registrada com o conteúdo e a resposta do regulador |
| Um reporte rejeitado pode ser corrigido e reenviado | Corrigidos os dados cadastrais, o registro volta para a fila |
| O mesmo reporte nunca é enviado duas vezes | Cada registro é assumido em uma única transação; uma segunda passada não o toca |
| Uma tela para conciliar com os registros oficiais da EPDK | Inventário do CSMS à esquerda, cadastro da EPDK à direita; registros sem correspondência se destacam |
| Cada rede de recarga escolhe sua própria instituição de pagamento | Definido por titular de licença |
| Sessões de um CSMS que não consegue enviar dados também são reportadas | O pacote lê a cada hora as sessões concluídas do CSMS conectado; um registro lido dessa forma nunca é reportado duas vezes |
| O resultado real de cada reporte volta para o CSMS | O resultado é entregue, assinado, no endereço definido pelo CSMS |
| O CSMS pode reler a partir de nós o que enviou | Todos os endpoints do lado receptor do OCPI 2.2.1 e 2.3.0 funcionam: locais, sessões, registros de recarga (CDR) e tarifas são enviados e relidos; cada endpoint foi testado um a um com uma chave real de CSMS |
| O registro de recarga de uma estação sem número da EPDK não se perde | O registro não é rejeitado, fica retido; assim que o número é informado, ele segue sozinho para a EPDK e o CSMS não precisa reenviá-lo |
| Um CSMS sem OCPI também pode se conectar | Uma interface REST de cinco eventos: sessão iniciada, encerrada, consumo, tarifa, falha |
| O relatório de vendas do GİB é gerado e assinado quando há um selo configurado | Sem selo, o documento é gerado mesmo assim e a tela informa que não está assinado |
Telas e o que elas comprovam
- Comunicação EPDK
- Prova na tela de que os reportes saem
- Reporte manual EPDK
- O operador fecha a lacuna entre o campo e o sistema
- Correspondência de cadastro
- A etapa mais crítica da implantação fica visível; uma correspondência errada não passa em silêncio
- Conciliação
- Pega o erro “achei que tinha enviado”
- Relatório de vendas GİB
- Os dados enviados ao integrador de documentos eletrônicos podem ser auditados
- Instituições de pagamento
- Em uma operação com várias redes, cada rede mantém seu próprio contrato
- Terminais de pagamento
- O QR do motorista nunca leva a uma página vazia
- Cadastros
- Uma operação com várias redes é gerida a partir de um único painel
Perguntas frequentes
- Precisamos alterar nosso CSMS?
- Não. Se o seu CSMS fala OCPI, não há nada novo a aprender; os papéis são os mesmos do fluxo padrão CPO→eMSP. Para um CSMS sem OCPI, há um gateway REST/webhook simples.
- O que acontece quando a regulação muda?
- A alteração é feita no Pacote de Conformidade; seu CSMS não é afetado. É exatamente por isso que este produto existe.
- Vamos saber se um reporte falhar?
- Sim. Cada tentativa é registrada com a resposta bruta do regulador. Se a fila parar, o indicador na tela mostra há quantos minutos ela está parada.
- Onde ficam nossos dados?
- O produto também pode ser instalado nos seus próprios servidores. Tarefas que envolvem dados de clientes, como a assinatura com o selo eletrônico, são feitas no local e não são enviadas para fora.
- Precisamos usar o SmartŞarj?
- Não. O Pacote de Conformidade funciona com qualquer CSMS; uma rede de recarga que não usa o SmartŞarj também pode adquiri-lo.