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. 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. 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.

Boa tarde Igor, Você poderia anexar o XML de uma nota para que eu possa fazer um teste?

Leandro, Após atualizar os fontes, você reinstalou o ACBr? Verifica se não tem nenhuma unit do componente com uma bolinha vermelha em seu ícone, caso afirmativo delete a unit e atualize novamente.

Boa tarde Claudio, Muito obrigado pela colaboração, já inclui na minha lista de tarefas. TK-3562

Obrigado por reportar. Fechando. Para novas dúvidas, criar um novo tópico.

Obrigado por reportar. Fechando. Para novas dúvidas, criar um novo tópico.

Juliano, O XML que consta na sua imagem na primeira postagem tem que ficar dentro de <xml> e </xml> Não esqueça de colocar o CDATA, pois o conteúdo da tag <xml> é uma string se não me falha a memória.

Boa tarde @Deunerf, Conseguiu passar pelo erro de validação com a dica que lhe dei na postagem anterior?

Juliano, No XML a ser enviado não precisa estar envelopado e dentro do grupo Body ?

Boa tarde Juliano, Você trabalha com qual linguagem?

Esse erro de validação ocorre quando você passa o valor tsNenhum, correto? Eu quero saber quando passa o valor stRetencao que faz com que ele gere a tag com o valor 1, o Rps não é processado com sucesso?

Leandro, Favor atualizar os fontes, reinstale o ACBr e faça novos testes. Com a alteração que fiz é para ele usar o código lote retornado pelo envio como sendo o numero do lote ao consultar o lote. De forma automatica.

Boa tarde Leandro, Já inclui na minha lista de tarefas para analise. TK-3561

Mas alterando o valor da tag para 1 não resolveu o problema? O Rps não foi processado com sucesso?

Boa tarde, Já esta no SVN.

Boa tarde Rogério, É preciso saber se com essa alteração não vai gerar um efeito colateral com as demais cidades que utilizam o mesmo provedor.

Boa tarde, No caso de Brasília a tag IssRetido é obrigatória.

Boa tarde, Favor atualizar todos os fontes de todas as pastas, reinstale o ACBr e faça novos testes.

Glauber, Já esta no SVN, favor atualizar os fontes, reinstale o ACBr e inicie os testes.

Bom dia, Qual é o código IBGE?

Deu certo a emissão?

Bom dia, Qual é o código IBGE da cidade, pois eu não encontrei nenhuma cidade chamada Paraíba, apenas Paraíba do Sul.

Bom dia, Eu não sei se para o provedor ISSNet esta invertido ou não, mas os valores gerados no XML são: 1 = stRetencao; 2 = stNormal; 3 = stSubstituicao e "uma string vazia" = stNenhum No caso de stNenhum a tag não vai ser gerada.

Bom dia Paulo, Pela mensagem de retorno do envio, nota-se que esse provedor faz um controle do numero do lote. Sendo assim se faz necessário descobrir qual é o numero do último lote enviado para dar continuidade. A sua aplicação vai ter que controlar o numero do lote, ou seja, ele vai ter que ser um numero sequencial.

Bom dia Glauber, Muito obrigado pela colaboração, já inclui na minha lista de tarefas. TK-3558