Édipo Rauber

Analisei parte da documentação, mas em nenhum lugar destaca que estaria retornando o R9001 ao consultar o protocolo do R2099. Como eu já disse acima, achei estranho esse comportamento pro R2099, sendo que pro R4099 sempre retorna o R9015, indiferente se há inconsistência ou não. Mas consegui contornar o problema aqui. Analisei a forma como o programa de exemplo do Reinf trabalha e adaptei meu fonte pra ler as inconsistências do R9001 também nesses casos. Obrigado pela ajuda.

Boa tarde A consulta dos demais registros está 100%, só usei como exemplo o R4099 que é parecido com o R2099: Mas no programa de exemplo, o comportamento é parecido: Consulta do R4099 sem erro: Consulta do R2099 sem erro: Consulta do R4099 com erro: Consulta do R2099 com erro: O R4099 com ou sem erro, retorna o R9015. Já o R2099 está retornando registros diferentes (R9011 ou R9001), oq eu acho estranho. Eu imaginei que sempre estaria retornando o R9011 ao consultar um protocolo do R2099, indiferente se tivesse erro ou não.

Identificamos uma situação e não sabemos se é problema na forma como estamos utilizando o componente da ACBr ou se pode ser algum problema no serviço da receita. Por exemplo: Ao enviar o evento de fechamento R4099, recebemos um protocolo o qual usamos para consulta. Nessa consulta, recebemos de retorno o evento R9015 que contém a tag <evtRetCons>. Correto. O mesmo para o R2099, onde ao consultar o protocolo recebemos de retorno o evento R9011 que contém a tag <evtTotalContrib>. Correto. Caso houver alguma inconsistência no evento de fechamento R4099, recebemos o R9015 com as informações dos erros que ocorreram, acessamos elas dessa forma: AACBrReinf.WebServices.Consultar.RetConsulta_R9015.evtRetCons.IdeStatus.regOcorrs; Correto. Agora quando está ocorrendo algum inconsistência no evento de fechamento R2099, não parece estar retornando o evento R9011. Inicialmente achei que fosse algum problema no componente quando estava sendo lido o XML, mas depois vi que o XML salvo não contém a tag <evtTotalContrib> com as inconsistências, mas sim a <evtTotal>. Incorreto. Ou seja, não está carregando as informações do retorno em AACBrReinf.WebServices.Consultar.RetConsulta_R9011.evtTotalContrib. Para simular a situação, no envio do R2099/R4099 informei um nome inválido no campo "Nome do responsável", tag <nmResp>. Em anexo segue XMLs da requisição do protocolo dos eventos de fechamento de cada um dos registros. Meu entendimento está correto? O WebService deveria retornar dessa forma pro R2099? Teria alguma maneira de contornar isso além de ler manualmente o XML pra buscar as informações que eu preciso? R2099.rar R4099.rar

Boa tarde. Estou adaptando nosso processo de envio do Reinf para a versão 2.1.2 e tentei aproveitar a informação da tag fechRet do InfoRecEv do R-9015, porém vi que não havia sido implementado. No manual da versão 2.1.2 esse campo ainda não está adicionado, porém na nota técnica publicada em 30/06/2023 foi documentada a inclusão dele no R-9015: http://sped.rfb.gov.br/estatico/76/AA9A434BB906C84F95694CBF3A13F4445CBDD9/Nota técnica EFD-Reinf 2-2023.pdf Segue XMLs de testes que usei para confirmar se a informação estava sendo retornada e o fonte alterado para aprovação. pcnReinfRetConsulta_R9015.pas fechamento_ID9015000000000000000000001233414379-R9015.xml reabertura_ID9015000000000000000000001840260796-R9015.xml

Bom dia Na versão 1.4 do "Manual de Orientação ao Desenvolvedor da EFD-Reinf" publicado mês passado vimos que a URL do método de consulta do evento de Totalizações (que retorna o R5011) foi alterado: De: https://reinf.receita.fazenda.gov.br/WsREINF/ConsultasReinf.svc e https://preprodefdreinf.receita.fazenda.gov.br/wsreinf/ConsultasReinf.svc Para: https://reinf.receita.fazenda.gov.br/WsREINFConsultas/ConsultasReinf.svc e https://preprodefdreinf.receita.fazenda.gov.br/WsREINFConsultas/ConsultasReinf.svc Acredito que foi feito devido a criação dos métodos de consulta dos recibos de entrega. Testei ambas URLs do ambiente de homologação e também a URL nova do ambiente de produção e todas funcionaram ao consultar o evento de totalizações. Como as antigas URLs ainda estão funcionando, não somos obrigados a alterar agora... mas acho interessante deixar conforme o manual. Em anexo estão os arquivos ACBrReinfServicos.ini e ACBrReinfServicos.res com as novas URLs na versão 1.40. ACBrReinfServicos.ini ACBrReinfServicos.res

Boa tarde Vi que no layout 1.4 do Reinf o campo evtPgtos do R2099 passou a ser opcional. Nas descrição do campo está assim: "Validação: Só preencher este campo se {perApur} <= [2018-10]." Acredito que esse campo deixou de existir porque era o indicador do R2070 que foi excluído nesse último layout. Pelo que eu entendi, não devemos mais gerar o evtPgtos a partir de 2018-11. Anexei o fonte onde adicionei uma condição verificando se o (perApur <= '2018-10') para somente assim gerar o evtPgtos. pcnReinfR2099.pas

Boa tarde Segue alteração na montagem do xml do registro R2099. A informação do campo compSemMovto estava sendo alimentada na tag errada. pcnReinfR2099.rar

Certo. Obrigado Rafael!

Humm. Certo. Perguntei isso pq fiz um teste com o ACBrNfe e lá consigo utilizar o certificado sem essa opção marcada. Mas se realmente não é possível utilizar dessa forma pro Reinf terei que verificar se os clientes instalaram o certificado dessa forma. Obrigado!

Boa tarde pessoal Instalei um certificado digital A1 na minha maquina, mas não marquei aquela opção que torna o certificado exportável. Quando vou transmitir o Reinf está retornando o erro: "Certificado não permite Exportar Chave Privada". Sei que marcando essa opção na instalação do certificado funciona 100%. Só queria confirmar se existe alguma configuração que eu possa usar pra conseguir utilizar um certificado A1 sem essa opção marcada, ou se realmente não é possível utilizar certificados instalados dessa forma pro Reinf. Obrigado!

Bom dia! Aconteceu o mesmo aqui. Ainda não sei como proceder pra reabrir o período.