Dúvida em relação ao retorno da consulta dos protocolos de fechamento (R2099/R4099)

[Édipo Rauber]

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

[renato.rubinho]

Boa tarde,

Aparentemente está correto, o evtTotal é o R9001, antigo R5001, que se tratava do retorno do envio síncrono, agora é o retorno da consulta dos eventos, fora os R4000, que retornam no R9005.

Veja no programa de exemplo como está sendo tratado o retorno da consulta para analisar os 4 tipos de retornos.

Consulte um protocolo sem erros do R2010 ou R2020, um do R2099, um do R4010 ou R4020 e um do R4099.

Consulte também cada um deles com erro.

Análise os 8 retornos para apurar como a Receita devolve as informações.

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

 

Editado 11 Outubro, 2023 por Édipo Rauber

[renato.rubinho]

Não me lembrava deste comportamento, mas se o componente está extraindo a mesma informação que consta no XML recebido, deve estar correto.

Para mim, o R9001 seria o retorno do processamento ao consultar todos, exceto os R4000 e o R9011 o retorno do R2099.

Uma hipótese é que a receita só devolva o R9011 quando não houverem erros e quando houverem, devolve o R9001 assim como os demais eventos.

O R9011 é como se fosse um totalizador dos R9001 dos demais eventos, então se ocorrerem erros talvez ele não seja gerado.

Veja se encontra algo a respeito na documentação.

http://sped.rfb.gov.br/destaques/show/1199

 

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

[renato.rubinho]

Obrigado por reportar.

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