Édipo Rauber
-
Total de ítens
11 -
Registro em
-
Última visita
Tipo de Conteúdo
Blocks
Notes ACBrLibNFe
Fóruns
Downloads
Calendário
Posts postados por Édipo Rauber
-
-
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?
-
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:
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
-
1
-
-
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.
-
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.
-
2
-
-
Boa tarde
Segue alteração na montagem do xml do registro R2099.
A informação do campo compSemMovto estava sendo alimentada na tag errada.
-
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!
-
1 hora atrás, Renato Rubinho disse:
1. Na situação atual, enviei o R2099 e retornou "2-Em Processamento"
1.1. Se tento enviar novamente, acusa <codResp>MS1078</codResp><dscResp>A EFD já foi fechada para o período informado, ou existe um evento de fechamento em processamento</dscResp>
1.2. Se tento enviar R2098, acusa <codResp>MS1060</codResp><dscResp>Não existe evento de fechamento para o período informado.</dscResp> como se não houvesse o R2099 ainda
Bom dia!
Aconteceu o mesmo aqui. Ainda não sei como proceder pra reabrir o período.
Dúvida em relação ao retorno da consulta dos protocolos de fechamento (R2099/R4099)
em ACBr-Reinf
Postado
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.