EFD-Reinf perguntas e respostas (parte II)

EFD-REINF PERGUNTAS E RESPOSTAS (PARTE II)

Seguem mais alguns esclarecimentos sobre a EFD-REINF conforme combinamos:

 

1) Como faço o cadastro da minha empresa de Tecnologia de Informação – TI para envio dos eventos do eSocial no ambiente de produção restrita? 

Não é necessário cadastro prévio para envio dos eventos. Basta a empresa seguir os procedimentos de envio descritos o Manual de orientação do Desenvolvedor.

 

2) Cliquei no link exibido na tela do menu da produção restrita, mas o navegador exibe uma página e não consigo prosseguir para enviar os eventos. Como encontro a ferramenta de envio dos eventos para empresa ?

O ambiente de produção restrita é um web service, ou seja, um ambiente de processamento que permite que as aplicações enviem e recebam dados por meio de arquivos XML (os eventos do eSocial). Não trata de uma ferramenta com interface visual de navegação, nos moldes do eSocial Doméstico, mas um ambiente tecnológico destinado às aplicações desenvolvidas pelas empresas de TI – Tecnologia da Informação.

 

3) A geração do Evento R-5001 será gerado pelo contribuinte, ou este evento será gerado pelo ambiente nacional da EFD-REINF e disponibilizado ao Contribuinte, para que este venha a ter ciência dos valores que este enviou a Receita Federal durante o período ? 

O evento R-5001 (totalizador) será retornado ao contribuinte automaticamente após a recepção de um evento válido.

 

4) Como faço para limpar a área de produção restrita e realizar novos testes nos mesmos períodos?

Não há como limpar a área de produção restrita, por enquanto.

5)Qual a URL de fato para acessar o ambiente de produção restrita da EFD-REINF?

Tenho a URL: https://reinf.receita.fazenda.gov.br/WsREINF/RecepçãoLoteReinf.svc e https://reinf.receita.fazenda/WsREINF/ConsultasReinf.svc, porém as mesmas me retornam `Connection time out´

Nenhum desses endereços, pois a EFD-REINF está em produção restrita (pré-produção)

O endereço correto é: https://preprodefdreinf.receita.fazenda.gov.br/RecepcaoLoteReinf.svc

 

6) O que fazer quando ocorre o erro “HTTP 403” ao tentar acessar o Webservice da EFD-Reinf ?

O errro “403 Forbidden” é um código de erro HTTP retornado pelo servidor web quando o utilizador ou programa tenta obter acesso a um recurso do servidor e este não permite.

Diversos podem ser os motivos que originam este tipo de erro, como por exemplo, acesso utilizando protocolo”http”quando deveria ser “https”, cadeia de certificado inválido ou certificado inválido, etc.

A seguir são listadas as causas comuns para este erro:

  • Acesso de execução negado.
  • Acesso de leitura negado.
  • Acesso de escrita negado.
  • SSL requerido.
  • Endereço de IP errado.
  • Certificado do cliente requerido.
  • Certificado do cliente revogado.
  • Certificado do cliente expirado.
  • Cadeira de certificado incorreta.

Assim, se ao tentar conectar com o ambiente da EFD-Reinf, foi retornada mensagem de erro 403-Forbidden (Acesso Negado), cuja mensagem em inglês em geral aparece como “403 Forbidden: Acess is denied. The request failed with HTTP status 403: Forbidden. The remote server returned an error: (403) Forbidden”, sugerimos algumas verificações como as que seguem:

a) Verifique se você esta utilizando https://

b)Verifique se seu certificado é válido.

c)Verifique se a cadeia do certificado é válida.

O certificado utilizado, para a transmissão do evento, deverá ter a amesma cadeira de certificado instalada no ambiente de produção restrita do SERPRO. A cadeira utilizada pelo servidor é: “Autoridade Certificadora Raiz Brasileira v5” (que pode ser encontrada no site http://www.iti.gov.br/repositorio/repositorio-ac-raiz : “Certificado da AC Raiz da ICP-Brasil v5”).

Verifique se seu certificado possui a cadeira de certificação abaixo instalada:

  • Autoridade Certificadora Raiz Brasileira v5
  • Autoridade Certificadora SERPRO v4
  • Autoridade Certificadora do SERPRO Final SSL 

 

7) O registro R-1000 será enviado no início e não precisará ser enviado novamente se não houver nenhuma alteração? Ou precisará ser enviado todo mês para abrir o período?

O evento R-1000 é um evento de tabela inicial, que só deve ser enviado uma única vez, quando as empresas forem entrar na obrigatoriedade da EFD-Reinf. Caso ocorra alterações na situação fática prestada pelo contribuinte no evento R-1000, deverá a empresa enviar o R-1000 para alterar essas informações prestadas anteriormente. A abertura do movimento será feita pelo envio do primeiro evento periódico da competência.

 

8) Qual é o objetivo do campo “indAcordoIsenMulta” (Indicativo da existência de acordo internacional para isenção de multa) do evento R-1000 da EFD-Reinf ? 

É um indicador que será utilizado posteriormente pela DCTFWeb para não haver cobrança de multa de mora, em função de acordo internacional celebrado pelo Estado Brasileiro e outros Estados ou Organismos internacionais.

 

9) Será necessário retificar a informação do contato do R-1000 caso a empresa faça uma retificação de um evento periódico, e o contato da competência do evento não seja o mesmo atual? 

Não. As informações de contato devem ser sempre as mais atuais, inclusive nos casos em que sejam prestadas informações de períodos anteriores.

 

10) Quem são estas EFRs do R-1000?

É o Ente Federativo Responsável pelo órgão público municipal ou estadual. Na EFD-Reinf, bem como no eSocial, as informações do setor público poderão ser prestadas de maneira centralizada pelo o ente federativo, ou descentralizada, sendo enviada por órgãos vinculados ao ente federativo separadamente. Assim, caso ocorra a segunda opção (descentralizada), o órgão no seu R-1000 deverá informar no grupo “infoEFR”, o ente federativo que é responsável por ele, o qual será validado na base cadastral da RFB.

 

11) Considerando que já tenha sido prestada informação anteriormente e se pretende prestar informações relacionadas a um novo período com informações diferentes, é necessário enviar um evento R-1000 informando fim da validade do evento enviado anteriormente? 

Não, basta enviar novo evento com nova data de início da validade (campo iniValid) no bloco de “inclusão”. Esse procedimento fará com que o evento enviado anteriormente fique válido no período entre a data inicial de validade daquele evento e a data de validade do novo evento. O evento enviado posteriormente ficará valido a partir da data inicial de validade informada no mesmo.

Em nosso próximo artigo falaremos sobre os eventos R-2010, R-2070, R-2099 entre outros.

Se sua empresa ainda não está preparada, ou tem dúvidas, fale com Camila Cristina, analista e consultora, e confira as dicas que ela tem para você considerar no projeto de sua empresa e atender plenamente esta obrigação acessória.

Para mais informações entre em contato conosco: 

Tel.: (11) 4227-9800

Email: contato@prodatasystems.com.br

Dúvidas? Entre em contato agora mesmo

FALE COM NOSSOS CONSULTORES