Entendendo o processo de mudanças no Reinf

[Italo Giurizzato Junior]

Olá pessoal,

Como temos anunciado a algum tempo, o REINF vem passando por um processo de mudanças, que envolve inclusive a tecnologia utilizada na recepção das informações por parte da receita.

 

Chegada da versão 2.1.1 

Nesta versão não foram somente mudanças de layouts ou inclusão de novos eventos, a versão 2.1.1 do REINF trouxe uma mudança na forma de envio e recepção dos eventos, passando a adotar a integração via API Rest e em modo assincrono.

Apesar do documento descrevendo o funcionando ter sido publicado no inicio de 2022, NÃO havia até poucas semanas atrás, a definição de QUANDO tais mudanças entrariam em vigor.

Sobre as datas

Divulgação das Mudanças

O Manual de orientação e ambientes de produção restrita (foram liberados no inicio de 2022, mas ainda havia indefinição de datas de inicio da vigência de tais mudanças

Implantação

Detalhamos melhor neste artigo, mas em resumo seriam:

• Fevereiro/2023 - Limite para aceitação dos eventos do layout 1.5.1 em produção restrita (Ambiente de Homologação)
• Março/2023 - Vigência do layout 2.2.1 para a competência  de março/2023
• Setembro/2023 - Envio da recepção dos eventos somente em forma Assíncrona  

Link do Manual do REINF
Manual de Orientação ao Desenvolvedor da EFD-Reinf – Lote Assíncrono - Versão 1.00.00 (rfb.gov.br)

 

Detalhando as Mudanças

Muito bem, até a versão 1.5.1 o ambiente que recepcionava os eventos trabalhava no modo síncrono, isso significa que ao enviar um evento do Reinf o webservice processava e caso estivesse tudo correto já era retornado o resultado do processamento, caso contrario era retornado a lista de erros.

A partir da versão 2.1.1 o ambiente que recepciona os eventos trabalha no modo assíncrono, isso significa que ao enviar um evento será retornado um numero de protocolo que usaremos em uma consulta para poder obter o resultado do processamento.

Como vocês podem ver agora se faz necessário 2 passos para obter o resultado do processamento do evento enviado.

Os fragmentos abaixo comprovam o que eu escrevi acima.

Citar

 

2.5 Protocolo de Recebimento do Lote

Para cada lote recebido a EFD-REINF retornará um protocolo, para consulta posterior ao resultado de seu processamento.

2.6 Consulta ao Protocolo de Lote

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.

 

Além do modo de envio passar a ser assíncrono a forma de comunicação também mudou, até a versão 1.5.1 tínhamos um ambiente baseado em WebService Soap, agora a partir da versão 2.1.1 teremos um ambiente baseado em API Rest conforme consta no fragmento abaixo.

Citar

 

3.5 Padrão de Comunicação

A comunicação será baseada em APIs REST, disponibilizadas pelo sistema EFD-REINF.

O meio físico de comunicação utilizado será a Internet, com o uso do protocolo HTTPS (TLS 1.1 ou 1.2), com autenticação mútua, que além de garantir um duto de comunicação seguro na Internet, permite a identificação do servidor e do cliente através de certificados digitais.

Caso seja necessário transmitir vários eventos em sequência sugere-se a utilização de conexão HTTPS persistente, conforme estabelecido na versão 1.1 do protocolo HTTP, evitando assim fechar e reestabelecer a conexão HTTPS para cada evento enviado

 

 

Estas informações foram extraídas na página do REINF

A documentação sobre este assunto está um pouco "escondida" no portal do REINF, mas para aqueles que desejarem conhecer, clique aqui.

http://sped.rfb.gov.br/projeto/show/1196

 

Sobre os componentes ACBr

Acompanhe as atualizações deste assunto no artigo a seguir.