EFD-Reinf: cuidados gerais com o ambiente de produção
O SPED – Sistema Público de Escrituração Digital é composto por vários módulos e, com certeza, a EFD-Reinf é o módulo que mais vem sendo discutido nos últimos meses dentro do fiscal.
Os sujeitos passivos obrigados à entrega da Escrituração Fiscal Digital irão declarar, dentre outras informações, as suas retenções. 
Os novos eventos da EFD-Reinf, a chamada série R-4000, começaram a ser entregues a partir da competência de setembro de 2023. As empresas que querem ter mais informações sobre a EFD-Reinf devem acessar o site do Sped, no módulo EFD-Reinf. Lá, estarão descritas diversas informações e notícias importantes, bem como manuais e leiautes. Os leiautes são importantes para quem precisa entender as regras dos XML, e o MOR para quem precisa entender melhor as regras de negócio. A transmissão de arquivos da EFD-Reinf utiliza o modelo de comunicação assíncrona via lotes, isso quer dizer que temos uma API para recepção e uma para consulta. É importante entender essa questão, porque, para que todas as etapas do processo de envio e entrega da EFD-Reinf sejam feitas, é necessário que o seu sistema faça as consultas nos webservices da Receita, e isso não acontece de imediato. Basicamente, nesse sistema, o declarante envia um XML, e ele é recepcionado pela API de recepção. Em regra, a API de recepção vai realizar validações no lote, e depois vai retornar um XML com o resultado. Esse XML conterá um número de protocolo somente se o evento (XML) tenha sido validado. Por exemplo, se você envia um R-1000 e a Receita o recebe com sucesso, ela vai validá-lo, estando ok, ela retornará um recibo, e não estando ok ela te retornará os problemas no seu arquivo. O XML com erro na sua estrutura ou versão do lote não será recebido. Então, nesse caso, em que o XML não foi processado com sucesso, ele não está entregue para o governo. Atualmente, os erros na entrega podem ocorrer pela conexão do certificado digital, erro na estrutura do arquivo ou em seu conteúdo. Assim, sempre verifique a lista de mensagens retornadas para poder encontrar a fonte do problema. A empresa que enviou os seus XMLs, recebeu o protocolo de recebimento, está nesse momento esperando a validação do governo. Para cada lote recebido, a EFD-Reinf retornará um protocolo, para consulta posterior. E quando o governo conseguir validar as informações, esse protocolo será usado para consultar o resultado do processamento. O fato de um XML ter sido enviado e estar como “em andamento”, significa que ele continua sendo analisado. No caso da empresa enviar, por exemplo, um R-4099, ele ficar “em andamento” e o retorno só vir depois da data fim de entrega, não se preocupe, a EFD-Reinf não será considerada como entregue fora do prazo. Nesse contexto, a Receita Federal entende que o contribuinte fez a parte dele, entregou o evento. Dentro desse cenário, como o processamento ficou a cargo da Receita, e ele é assíncrono, não faria sentido a Receita penalizar o contribuinte e considerar apenas a data final do resultado do processamento. Por isso, a data de entrega que sempre será observada é a data do envio do evento, caso ele fique como “em processamento”. Os eventos da EFD-Reinf, tanto R-2000 como R-4000, podem ser enviados em dois ambientes: de produção restrita, e de produção. Se qualquer evento, seja do R-2000 ou R-4000, for enviado no ambiente de produção restrita, é como se ele tivesse sido enviado apenas de teste, ou seja, sem validade nenhuma para fins de cumprimento de obrigações acessórias. Por isso, é importante que todos os seus eventos, R-2000, R-4000, R-1000, R-1070 e etc, sejam enviados pelo ambiente de produção e não de produção restrita. Para o correto envio dos eventos R-2000,0 R-4000 e demais é necessário utilizar certificado digital, que pode ser do contador, pode ser o da empresa, ou do representante legal da empresa para envio da EFD-Reinf. Para os casos de se utilizar o certificado do contador ou representante é necessário ter procuração. A transmissão pode ser feita por e-CPF (e-PF) ou e-CNPJ (e-PJ). Uma das funcionalidades do eCAC é permitir gerar essas procurações, para a EFD-Reinf, o processo é rápido e gratuito. As entregas devem ser feitas com certificado digital tipo A1 (mais recomendado) ou A3 (comumente gera mais problemas). Como o certificado A1 fica armazenado no próprio computador, ele é mais indicado para envio da EFD-Reinf. Lembrando que os certificados digitais do tipo A3 são armazenados em meio físico (atualmente smart card ou token), o que dificulta a entrega e pode gerar erros na transmissão. O certificado é exigido em dois momentos distintos, na transmissão (antes de ser iniciada a transmissão é verificado o certificado e sua segurança de tráfego), e na assinatura dos documentos. Por fim, o envio do evento de fechamento deve ser o último do lote, pois, a EFD-Reinf processará os eventos conforme for recebendo, e se por ventura, você enviar um R-4020 e R-4099 juntos, ele poderá processar o R-4099 primeiro, e não processar seu R-4020. Tendo em vista essa situação, normalmente os sistemas já têm controles ou avisos para impedir que sejam enviados vários XML misturados, mas é uma informação importante.
Os novos eventos da EFD-Reinf, a chamada série R-4000, começaram a ser entregues a partir da competência de setembro de 2023. As empresas que querem ter mais informações sobre a EFD-Reinf devem acessar o site do Sped, no módulo EFD-Reinf. Lá, estarão descritas diversas informações e notícias importantes, bem como manuais e leiautes. Os leiautes são importantes para quem precisa entender as regras dos XML, e o MOR para quem precisa entender melhor as regras de negócio. A transmissão de arquivos da EFD-Reinf utiliza o modelo de comunicação assíncrona via lotes, isso quer dizer que temos uma API para recepção e uma para consulta. É importante entender essa questão, porque, para que todas as etapas do processo de envio e entrega da EFD-Reinf sejam feitas, é necessário que o seu sistema faça as consultas nos webservices da Receita, e isso não acontece de imediato. Basicamente, nesse sistema, o declarante envia um XML, e ele é recepcionado pela API de recepção. Em regra, a API de recepção vai realizar validações no lote, e depois vai retornar um XML com o resultado. Esse XML conterá um número de protocolo somente se o evento (XML) tenha sido validado. Por exemplo, se você envia um R-1000 e a Receita o recebe com sucesso, ela vai validá-lo, estando ok, ela retornará um recibo, e não estando ok ela te retornará os problemas no seu arquivo. O XML com erro na sua estrutura ou versão do lote não será recebido. Então, nesse caso, em que o XML não foi processado com sucesso, ele não está entregue para o governo. Atualmente, os erros na entrega podem ocorrer pela conexão do certificado digital, erro na estrutura do arquivo ou em seu conteúdo. Assim, sempre verifique a lista de mensagens retornadas para poder encontrar a fonte do problema. A empresa que enviou os seus XMLs, recebeu o protocolo de recebimento, está nesse momento esperando a validação do governo. Para cada lote recebido, a EFD-Reinf retornará um protocolo, para consulta posterior. E quando o governo conseguir validar as informações, esse protocolo será usado para consultar o resultado do processamento. O fato de um XML ter sido enviado e estar como “em andamento”, significa que ele continua sendo analisado. No caso da empresa enviar, por exemplo, um R-4099, ele ficar “em andamento” e o retorno só vir depois da data fim de entrega, não se preocupe, a EFD-Reinf não será considerada como entregue fora do prazo. Nesse contexto, a Receita Federal entende que o contribuinte fez a parte dele, entregou o evento. Dentro desse cenário, como o processamento ficou a cargo da Receita, e ele é assíncrono, não faria sentido a Receita penalizar o contribuinte e considerar apenas a data final do resultado do processamento. Por isso, a data de entrega que sempre será observada é a data do envio do evento, caso ele fique como “em processamento”. Os eventos da EFD-Reinf, tanto R-2000 como R-4000, podem ser enviados em dois ambientes: de produção restrita, e de produção. Se qualquer evento, seja do R-2000 ou R-4000, for enviado no ambiente de produção restrita, é como se ele tivesse sido enviado apenas de teste, ou seja, sem validade nenhuma para fins de cumprimento de obrigações acessórias. Por isso, é importante que todos os seus eventos, R-2000, R-4000, R-1000, R-1070 e etc, sejam enviados pelo ambiente de produção e não de produção restrita. Para o correto envio dos eventos R-2000,0 R-4000 e demais é necessário utilizar certificado digital, que pode ser do contador, pode ser o da empresa, ou do representante legal da empresa para envio da EFD-Reinf. Para os casos de se utilizar o certificado do contador ou representante é necessário ter procuração. A transmissão pode ser feita por e-CPF (e-PF) ou e-CNPJ (e-PJ). Uma das funcionalidades do eCAC é permitir gerar essas procurações, para a EFD-Reinf, o processo é rápido e gratuito. As entregas devem ser feitas com certificado digital tipo A1 (mais recomendado) ou A3 (comumente gera mais problemas). Como o certificado A1 fica armazenado no próprio computador, ele é mais indicado para envio da EFD-Reinf. Lembrando que os certificados digitais do tipo A3 são armazenados em meio físico (atualmente smart card ou token), o que dificulta a entrega e pode gerar erros na transmissão. O certificado é exigido em dois momentos distintos, na transmissão (antes de ser iniciada a transmissão é verificado o certificado e sua segurança de tráfego), e na assinatura dos documentos. Por fim, o envio do evento de fechamento deve ser o último do lote, pois, a EFD-Reinf processará os eventos conforme for recebendo, e se por ventura, você enviar um R-4020 e R-4099 juntos, ele poderá processar o R-4099 primeiro, e não processar seu R-4020. Tendo em vista essa situação, normalmente os sistemas já têm controles ou avisos para impedir que sejam enviados vários XML misturados, mas é uma informação importante.Fonte: EFD-Reinf: cuidados gerais com o ambiente de produção
