[Atualizado com a versão 2.3] Publicada uma nova versão do Manual de Orientação ao Desenvolvedor da EFD-Reinf, leia esse artigo e fique sempre atualizado!
O Projeto SPED segue evoluindo e junto a ele os seus módulos. A EFD-Reinf está com um novo leiaute, o 2.1.2, para implantação em produção a partir da competência de Setembro/2023, mais precisamente dia 21/09/2023. O novo leiaute contempla novos registros para envio de dados relacionados aos impostos retidos: IR, CSLL, COFINS, PIS/PASEP incidentes sobre os pagamentos efetuados a pessoas físicas e jurídicas.
Com o novo leiaute, temos novos registros, novos grupos e campos Desenvolvedor! Aqui você fica por dentro do leiaute 2.1.2; pois nesse artigo vamos falar sobre as últimas versões do Manual de Orientação ao Desenvolvedor. Boa leitura!
Manual de Orientação ao Desenvolvedor
A mudança iniciou com a publicação no final de outubro de 2022, da versão 2.0 do Manual de Orientação ao Desenvolvedor, unificando o manual anterior de transmissão síncrona com as novas informações para transmissão assíncrona, especialmente da família R-4000.
Posteriormente novas versões foram publicadas; no mês de fevereiro de 2023 a versão 2.1 apresenta atualizações quanto aos retornos HTTP para as APIs do modelo assíncrono com os principais códigos de retorno, e uma nova API REST para Consulta a Recibo de Entrega de Evento: para cada tipo de evento, há um endpoint e parâmetros específicos. O endereço para consultas terá o seguinte padrão: https://[dominio]/consulta/reciboevento/[endpoint]/[parametros] onde:
[dominio]: ambiente de produção restrita ou produção
[endpoint]: endpoint específico de cada evento
[parametros]: parâmetros específicos de cada evento. Conforme definido no Manual.
Exemplo: https://pre-reinf.receita.economia.gov.br/consulta/reciboevento/R1000/1/12345678
Acima, é exemplificado a consulta em ambiente de produção restrita do evento R-1000, para tpInsc = 1 e nrInsc = 12345678
Método HTTP: GET
Requer Certificado de Cliente?: Sim
Parâmetro/uri: Específicos por tipo de evento
Schema Retorno: retornoRecibosChaveEvento-v1_05_01.xsd
URL base: Ambiente de Produção: (a ser definido) | Ambiente de Produção Restrita: https://pre-reinf.receita.economia.gov.br/consulta/reciboevento/ + [endpoint e parâmetros específicos de cada evento]
Documentação Swagger: (Será disponibilizada somente em produção restrita) https://prereinf.receita.economia.gov.br/consulta/swagger/index.html
Retornos HTTP esperados
- HTTP 200 : Foram encontrados dados para os parâmetros informados. No body é retornado o xml conforme o schema Retorno.
- HTTP 404 : Endpoint não encontrado ou não forma encontradas informações de eventos transmitidos que atendessem aos parâmetros informados. Verifique se foi montado o endpoint com todos os parâmetros corretamente, e em caso positivo, no body será retornado o xml contendo a informação de dados não encontrados.
- HTTP 422 : Consulta realizada gerou ocorrências. No body é retornado o xml com as ocorrências a serem resolvidas pelo cliente
- HTTP 495,496 : Certificado não aceito na conexão a API. Verifique se o certificado está expirado ou revogado.
- HTTP 500 : Erro interno na EFD-REINF. No body é retornado o xml contendo um identificador do erro para acionamento da equipe de suporte do sistema.
Já a versão 2.2, também publicada em fevereiro, veio para complementar a anterior, incluindo informações dos endpoints dos serviços de consulta do recibo dos eventos da série R-4000, em que não tenha sido informado o CPF e/ou o CNPJ do beneficiário. Para os serviços de consulta, os endpoint REST contam agora com o parâmetro cpfBenef e cnpjFonte para eventos que não foi informado o CPF/CNPJ do beneficiário. Os eventos que sofreram alterações foram: R-4010, R-4020, R-4080.
A versão 2.3 publicada em 03 de agosto de 2023, atualiza o item 3.6 – Assinatura Digital, onde os certificados de autenticação de servidor (SSL/TLS) não podem mais ter o atributo “não repúdio” habilitado. Sendo assim, os certificados de raiz v10 que não possuírem esse atributo devem ser utilizados apenas para autenticação, evitando-se o seu uso para assinaturas digitais.
Foram publicadas as URLs de produção das APIs de envio e consulta do modelo assíncrono que até então não haviam sido publicadas:
-
- API envio lote modelo assíncrono:
- Ambiente de Produção: https://reinf.receita.economia.gov.br/recepcao/lotes (disponível somente após a data da implantação prevista no portal do Sped 21/09/2023).
- Ambiente de Produção Restrita: https://pre-reinf.receita.economia.gov.br/recepcao/lotes (já disponível).
- API envio lote modelo assíncrono:
- API consulta lote modelo assíncrono:
-
- Ambiente de Produção: https://reinf.receita.economia.gov.br/consulta/lotes/{numeroProtocolo} (disponível somente após a data da implantação prevista no portal do Sped 21/09/2023).
- Ambiente de Produção Restrita: https://pre-reinf.receita.economia.gov.br/consulta/lotes/{numeroProtocolo} (já disponível).
Com a publicação das URLs, os principais códigos de retorno HTTP e seu significado para as novas APIs do modelo assíncrono de envio e consulta passaram por atualizações.
Como irá funcionar o envio de lotes de eventos assíncronos?
Os eventos serão transmitidos pela Internet para o Ambiente Nacional, de forma agrupada através de lotes. Inicialmente, a quantidade máxima de eventos permitidos por lote assíncrono para envio para a EFD-Reinf será de 50 (cinquenta) eventos, porém essa quantidade poderá ser alterada conforme forem sendo realizados os testes; a Receita Federal do Brasil irá estabelecer qual será o tamanho médio de cada evento, logo, informamos que novas versões do Manual de Orientação do Desenvolvedor serão publicadas.
No Ambiente Nacional, após a recepção do lote com sucesso, os eventos serão extraídos e submetidos a validações quanto ao conteúdo e quanto aos outros eventos recebidos anteriormente, garantindo a qualidade da informação. Os eventos deverão ser assinados digitalmente, de maneira a garantir a integridade dos dados e a autoria do emissor. No caso de procurador, a procuração eletrônica deverá ser cadastrada no portal do e-CAC.
Ao ser enviado o lote de eventos, será executada a validação, onde serão verificados o certificado da conexão, a estrutura e versão do lote. As validações dos eventos serão executadas por processamento assíncrono, sendo feito a validação da estrutura, onde será verificada a estrutura do arquivo, de acordo com o tipo de evento. Posteriormente, será feita a validação de conteúdo informado no evento.
Caso ocorra erro na validação do lote, estrutura ou seja detectada alguma inconsistência, o evento não será recebido. As validações realizadas e a lista das mensagens retornadas podem ser encontradas no Portal do Sped.
Para cada lote recebido a EFD-REINF retornará um protocolo. A consulta ao protocolo retornará um XML contendo a situação “Em Processamento”, caso o lote ainda não tenha sido processado. Após o lote ter sido processado, a consulta retornará um XML com o resultado do processamento de todos os eventos do lote, contendo todos os seus respectivos recibos ou inconsistências.
O versionamento dos leiautes dos eventos serão por tipo de evento. Assim, a alteração do leiaute de um determinado tipo de evento não afeta a versão dos demais. Os leiautes válidos em um determinado período serão empacotados e distribuídos através dos “Pacotes de liberação”. Cada pacote de liberação tem os leiautes dos tipo de eventos suportados pela EFD-REINF com as suas respectivas versões, com os seguintes princípios:
- O leiaute do tipo de evento compreende apenas a sua estrutura. Assim, um mesmo leiaute pode ter diferentes conjuntos de regras e valores válidos durante o seu período de vigência. A alteração dos valores válidos ou o conjunto de regras de um leiaute, sem alteração de sua estrutura, será realizada através da atualização esse manual, ou seja, não haverá alteração da versão do leiaute.
- Para cada tipo de evento haverá apenas uma versão de leiaute vigente em um determinado período.
- Cada XSD é identificado por um único Namespace e cada XSD representa apenas um leiaute.
- O Sistema EFD-REINF identificará o tipo e a versão do leiaute do evento através do namespace do Xml do evento.
- Padrão de identificação da versão de Leiaute será X.Y.Z e do Schema XML – XSD X_Y_Z. Onde:
- X -> utilizado para representar mudanças muito significativas (Reestruturação do evento)
- Y -> utilizado para representar mudanças estruturais comuns (Inclusão/exclusão de campos, alteração de tipo ou formato do conteúdo de campo, dentre outras).
- Z -> utilizados para corrigir erros em XSD publicados e, possivelmente, já utilizados. Neste caso haverá uma substituição do “Pacote de liberação” do referido período.
A EFD-Reinf terá dois serviços (APIs REST) para o modelo de Lotes Assíncronos da REINF:
- Produção Restrita:
-
- Endpoint Recepção (POST) :
- https://pre-reinf.receita.economia.gov.br/recepcao/lotes
- Endpoint Consulta (GET) :
- https://pre-reinf.receita.economia.gov.br/consulta/lotes/{numeroProtocolo}
- Documentação swagger (disponível somente em produção restrita) :
- API Recepção : https://pre-reinf.receita.economia.gov.br/recepcao/swagger/index.html
- API Consulta : https://pre-reinf.receita.economia.gov.br/consulta/swagger/index.html
- Endpoint Recepção (POST) :
- Produção:
- Endpoint Recepção (POST) :
- https://reinf.receita.economia.gov.br/recepcao/lotes
- Endpoint Consulta (GET) :
- https://reinf.receita.economia.gov.br/consulta/lotes/{numeroProtocolo}
- Endpoint Recepção (POST) :
(* Atenção : As APIs de produção acima ainda não estão disponíveis para uso. Estarão disponíveis na data a ser informada no portal do Sped).
O lote enviado, o retorno e consulta terão o formato de XML; a estrutura (schemas) poderá ser acessada no Portal do Sped.
Esta versão apenas receberá eventos e permitirá acionar a API de consulta do resultado do processamento do lote. É uma versão apenas para testes da parte de comunicação assíncrona com as rotinas de envio e consulta. Não estará disponível na mesma, o processamento e a validação dos eventos enviados no lote.
Sendo assim, neste primeiro momento, a consulta do resultado do processamento retornará um XML contendo a situação “Em Processamento”, pois os lotes ainda não serão processados.
Futuramente será disponibilizada uma nova versão desses serviços, que realizará a validação e o processamento dos eventos. Não foi divulgada a data de entrada em produção, quanto a produção restrita.
Por que investir em APIs prontas?
Diante da complexidade e de tantos detalhes a serem desenvolvidos no seu software, a forma mais eficiente de garantir a eficiência na hora de implementar EFD-Reinf é optar por uma API pronta.
Contar com uma empresa de tecnologia parceira é o melhor caminho para evitar problemas na criação dos módulos, principalmente se levar em conta que a solução é produzida com foco total no seu objetivo. Além disso, o processo é muito mais rápido: em vez de levar meses para desenvolver a sua API própria, a terceirização permite que a integração seja feita em questão de dias.
É isso que ocorre com o componente EFD-Reinf da TecnoSpeed, que é integrado em menos de 7 dias. O nosso produto executa todo o processo de geração, transmissão e consulta dos eventos e está sempre atualizado. Isso porque acompanhamos frequentemente as alterações da legislação para fornecer a melhor solução para o seu ERP.
Confira todas as vantagens de escolher a nossa API para implementar EFD-Reinf no seu software e invista nessa facilidade!
