Renato Rubinho

Boa tarde, Você anexou apenas os arquivos de retorno, não temos como analisar o que foi enviado. Simulado o mesmo cenário e não ocorreram erros. 1. Enviado R1000 com o início da validade 07/2023, sem fim de validade ( IMG_001.png ) 2. Enviado R4020 com o perApur de 09/2023 e não ocorreram erros ( IMG_002.png ) Seguem algumas verificações para identificar se existe algum problema de preenchimento aí. Revise todos os pontos a seguir e, caso o problema persista, envie os xmls de envio e retorno do R1000 e R4020 para análise Confirme se está enviado o evento R4020 para o mesmo cnpj que está consultando no eCac Confirme se está enviando o período correto Confirme se está consultando o protocolo correto Tente enviar outro R4020 e consulte o novo protocolo recebido

Boa tarde, Coloque o timeout acima de 30k. Essa mensagem veio no xml? Se for um erro na comunicação e o componente não receber o retorno, não tem como tratar.

E a respeito das outras confirmações? Criada TK-4501 para análise.

Boa tarde, Está utilizando o ACBrNFSeX, com os fontes atualizados e reinstalou os componentes após atualizar? Teste com o programa de exemplo se ocorre o mesmo problema, pois é um retorno do provedor e deve estar faltando preencher algo que eles não trataram corretamente a exceção. Compare o rps gerado com o manual se está preenchendo todos os campos obrigatórios.

Boa tarde, Veja como é feito no programa de exemplo. ../trunk2/Exemplos/ACBrDFe/ACBrNF3e/

Boa tarde, Está enviando no mesmo ambiente (Produção) que foi consultado no eCac? No erro do R1000, você está alterando o período? Se sim, confirme se na validade original está preenchendo corretamente, para alterar você deve preencher a novaValid. Envie por e-mail os xmls de envio e retorno para analisarmos o que foi enviado e o retorno exato do serviço

Boa noite, Obrigado pela colaboração. Foram enviadas correções ao SVN que devem resolver o problema relatado, Rev-30742 Por favor atualize os fontes, reinstale os componentes, verifique se o problema foi resolvido e, se possível, nos informe se foi o resultado esperado.

Boa tarde, Obrigado pela contribuição. Criada TK-4495 para análise e possível envio ao SVN.

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

Boa noite, Tente esta opção: ImprimeDescAcrescItem Conforme descrito no tópico a seguir, use 1 para nunca imprimir ou 2 para imprimir somente quando houver valor.

Boa noite, Se for A3 certifique-se de estar com todas as atualizações do Windows em dia. Se for certificado A1, tente com OpenSSL, depende apenas das dlls para um bom funcionamento. Veja o tópico a seguir para configurar e pegar as devidas dlls. Force o preenchimento da tag que está acusando o problema e veja se consegue enviar no programa de exemplo. <cLocEmi>2927408</cLocEmi>

Boa noite, Veja se tem relação com a solução passada neste tópico.

Boa noite, A VersaoDF está errada. https://acbr.sourceforge.io/ACBrLib/ConfiguracoesdaBiblioteca16.html

Boa tarde, A nova versão do Reinf que mudou. Até a versão 1.5 ele era síncrono, você enviava o evento e já recebia o retorno com o resultado do processamento. Exceto pelo R2099, que já era assíncrono, você recebia um número de protocolo e precisava consultá-lo para obter o resultado do processamento. Agora, na versão 2.1.2, todos os eventos são assíncronos, você vai enviar, pegar o protocolo e consultar o resultado do processamento. Veja o manual a seguir para entender a diferença entre as versões. https://svn.code.sf.net/p/acbr/code/tools/DFe/Reinf/ManDesenvolvedor/ManualOrientacaoDesenvolvedor-REINF-v2.3.pdf Veja o método a seguir, na documentação do monitor, para consultar o protocolo. https://acbr.sourceforge.io/ACBrMonitor/ReinfConsultarReinf.html

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

Boa tarde, Enviado ao SVN, na Rev-30734, alterações visando corrigir este problema. Por favor, queira atualizar seus fontes, reinstalar o ACBr para realizar novos testes e reportar qualquer problema. Efetuado o mesmo tratamento para a leitura do INI.

Boa tarde, Não me lembro de alguém ter utilizado este tipo de certificado. Você conseguiu assinar em alguma máquina com ele? Como ele funciona, você instala este programa e ele "gera" o certificado ali na lista de certificados do Windows que você printou? O A1 precisa ter a opção de exportação habilitada para funcionar, esse não deve funcionar desta forma, talvez mais como uma leitora/token. Ele gera um número de série do certificado? Uma hipótese é configurar no componente o número de série, senha e ver se funciona. Tem que ser com winCrypt mesmo e todas as atualizações do Windows devem estar em dia.

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

Boa tarde, O limite é de 50 eventos por lote no novo modelo assíncrono, no modelo síncrono são 100. 5. Envio de Lote - modelo assíncrono A partir da entrada dos novos eventos da série R-4000, a EFD-REINF possuirá o modelo de envio de lote com processamento assíncrono. A princípio para os lotes no modelo assíncrono a quantidade máxima será de 50 (cinquenta) eventos. Essa quantidade poderá ser alterada durante os testes e até o efetivo início da recepção em produção. Neste caso o manual será atualizado. Segue manual com maiores informações. http://svn.code.sf.net/p/acbr/code/tools/DFe/Reinf/ManDesenvolvedor/ManualOrientacaoDesenvolvedor-REINF-v2.3.pdf

Seu XML está indentado e com quebras de linhas. Consegue gerar um XML sem essas mudanças? Ou preencha os valores no programa de exemplo e gere o XML através dele para verificar se tem relação com o problema.

Bom dia, Está testando em produção? O ambiente de produção está indisponível hoje.

Bom dia, Conforme publicação de ontem do portal do Reinf, o ambiente de Produção estará indisponível das 07h às 17h de 21/09/2023. http://sped.rfb.gov.br/pagina/show/7271 Publicado em 20/09/2023 Comunicamos que o ambiente de produção da EFD-Reinf estará indisponível do período de 7h às 17h do dia 21/09/2023 para realização da migração da versão 1.5.1 para a versão 2.1.2 e implantação da recepção dos eventos da série R-4000. A aplicação da EFD-Reinf acessada pelo e-CAC (https://www3.cav.receita.fazenda.gov.br/ ) também ficará indisponível nesse período. Após concluída a implantação, apresentará mudanças na interface visual buscando facilitar sua utilização com a implantação da série R-4000.

Boa noite Marcelo, Obrigado pelos esclarecimentos. O S-1220, mesmo não tendo sido implementado, assim como qualquer outro campo ou grupo que seja removido, evitamos excluir propriedades, classes e units do componente para evitar a quebra na compilação, caso alguém tenha alguma referência em suas aplicações, ainda mais em meio a uma implementação de nova versão com tantas mudanças. Com relação aos eventos S-8000 ficou claro que não tem necessidade de implementação no componente.

Boa noite, Foi enviado ao SVN na Rev-30712 alterações visando corrigir este problema. Por favor, queira atualizar seus fontes, reinstalar o ACBr para realizar novos testes e reportar qualquer problema. Efetuado teste com o programa de exemplo, prenchendo as mesmas informações do xml recebido no e-mail e o evento foi processado com sucesso.

Boa tarde @Andergoncalves Obrigado pela contribuição. As implementações da versão 1.2, inclusive seus fontes, foram enviadas ao SVN na Rev-30703 . Por favor, queira atualizar seus fontes, reinstalar o ACBr para realizar novos testes e reportar qualquer problema.