> For the complete documentation index, see [llms.txt](https://docs.enapi.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.enapi.com/enapi-documentation-pt/documentacao-tecnica/roaming-em-2.1.1.md). # Roaming em 2.1.1 **Tudo o que precisa de saber sobre o OCPI 2.1.1 e a plataforma ENAPI** O ENAPI Transaction Broker suporta totalmente o OCPI 2.1.1. No entanto, quando necessário, o esquema foi alargado para: * Implementar a topologia "hub", que não é suportada nativamente pela versão 2.1.1 * Disponibilizar funcionalidades de valor acrescentado vistas noutras versões e protocolos do OCPI * Garantir um funcionamento fluido para os parceiros na versão do OCPI da sua escolha O roaming na 2.1.1 com um parceiro que implementa OCPI 2.2.1+ tem o maior impacto. Do mesmo modo, é importante estar ciente das limitações ao fazer roaming com um parceiro 2.1.1 em ligações OCPI 2.2.1+. Este documento descreve todas as adições efetuadas e as ressalvas ao fazer roaming entre versões do OCPI. ## 🔌 Parceiros de Roaming ### Credenciais da ENAPI Como parte do handshake de Credenciais, a ENAPI fornecerá ao seu sistema as suas próprias credenciais de hub: `DE*ENA`. ### Receber credenciais do parceiro de roaming No OCPI 2.1.1 não há forma de a ENAPI partilhar a lista de parceiros de roaming dos quais receberá pedidos na plataforma ENAPI. Deve preparar a sua plataforma para isso antes de fazer roaming com um parceiro. Os dados recebidos de parceiros de roaming através da ENAPI terão o `country_code` e `party_id` do parceiro de roaming no URL. Se a sua plataforma não suportar isto, a ENAPI pode usar as suas próprias credenciais no URL. Se as credenciais da ENAPI forem usadas no URL, dados como localizações e tokens que precisem de ser mapeados internamente para um operador terão de o ser por outros meios. A ENAPI modifica o operador da Location e o emissor do Token no OCPI 2.1.1 por este motivo. A forma como isso é feito é descrita na secção de Interoperabilidade de Versões abaixo. ## 🌐 Interoperabilidade de Versões O OCPI 2.1.1 é a versão com mais alterações entre todas as versões do OCPI implementadas pela ENAPI. Esta secção contém informações para parceiros que suportam OCPI 2.1.1, ou que fazem roaming com parceiros OCPI 2.1.1. ### Roaming com OCPI 2.1.1 #### Alterações Comuns Cada objeto OCPI de nível superior (*Location, Tariff, Token, Session, CDR*) contém o `country_code` e `party_id` para ajudar na identificação do operador, para efeitos de faturação. Não têm de ser definidos pela entidade 2.1.1 remetente. São adicionados pela ENAPI (os recetores 2.1.1 podem optar por não os receber). | **Propriedade** | **Tipo** | **Cartão.** | **Descrição** | | --------------- | --------- | ----------- | ---------------------------------------------------------------------- | | country\_code | String(2) | ? | Código de país ISO-3166 alpha-2 do operador que 'possui' este objeto. | | party\_id | String(3) | ? | ID do operador que 'possui' este objeto (seguindo o padrão ISO-15118). | #### Nova funcionalidade no OCPI 2.2.1+ Não receberá campos e valores de enumeração adicionados no OCPI 2.1.1, a menos que sejam explicitamente retroportados pela ENAPI. Quando necessário, a ENAPI mapeia os valores incompatíveis para valores compatíveis com o OCPI 2.1.1. ### Localizações * O `operator.name` campo também é definido como o `country_code` e `party_id` do proprietário da Location, caso os valores acima não sejam suportados. Por exemplo, se a Location tiver `country_code=DE` e `party_id=CPO`, o valor do nome do operador será `DE*CPO`. * O código postal é opcional no OCPI 2.2.1+. Se receber uma Location de um parceiro 2.2.1+ que não inclua o `postal_code`, este valor será uma string vazia. * Conectores que têm incompatíveis `padrão`, `formato` e `power_type` valores (isto é, introduzidos em versões subsequentes do OCPI) são omitidos no OCPI 2.1.1. Não serão partilhados com parceiros de roaming OCPI 2.1.1. * Se um parceiro de roaming 2.2.1+ atribuir vários IDs de Tariff a um Connector, a ENAPI tentará inferir o ID de Tariff correto para parceiros OCPI 2.1.1, com base no tipo de Tariff. Se não for possível selecionar nenhum ID de tarifa, este é omitido. * O `max_electric_power` campo foi retroportado para o OCPI 2.1.1 (ver abaixo). #### Connector ***Objeto*** Tornado disponível para recetores OCPI 2.1.1 ao fazer roaming com parceiros 2.2.1+. | **Propriedade** | **Tipo** | **Cartão.** | **Descrição** | | -------------------- | -------- | ----------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | max\_electric\_power | int | ? |

Potência elétrica máxima que pode ser fornecida por este conector, em watts (W). Quando a potência elétrica máxima for inferior ao valor calculado a partir da tensão e da amperagem, este valor deve ser definido.

Por exemplo: um ponto de carregamento DC que pode fornecer até 920 V e até 400 A pode ser limitado a uma potência máxima de 150 kW (max\_electric\_power = 150000). Dependendo do carro, pode fornecer a tensão ou a corrente máximas, mas não ambas ao mesmo tempo.

Nos pontos de carregamento AC, o número de fases utilizadas também pode influenciar a potência máxima.

| #### Tokens * O `emissor` campo também é definido como o `country_code` e `party_id` do proprietário do Token, caso os valores acima não sejam suportados. Por exemplo, se o Token `country_code=DE` e `party_id=MSP`, o valor do emissor será `DE*MSP`. #### Sessions e CDRs * No OCPI 2.1.1, a ENAPI utiliza `PENDENTE` como estado de sessão de recurso, no caso de receber, por exemplo, o `RESERVA` valor de estado na 2.2.1 ou 2.3.0. * O `FIXO` A dimensão CDR foi removida das versões subsequentes do OCPI. As dimensões CDR com este tipo são filtradas na versão 2.2.1+. * O OCPI 2.2.1 introduziu o conceito de **referências de autorização**. Isto foi retroportado para a 2.1.1 através do `authorization_id` campo em Commands, Sessions e CDRs. Quando receber um Command que contenha um `authorization_id`, pode definir esse mesmo valor na Session correspondente (e no CDR). Se não o fizer, tentaremos defini-lo nós próprios.
--- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://docs.enapi.com/enapi-documentation-pt/documentacao-tecnica/roaming-em-2.1.1.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.