Renato Rubinho

Fechando tópico antigo. Para novas dúvidas, favor abrir novo tópico.

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

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

Boa tarde, Veja as configurações possíveis em Impressão/NFe https://acbr.sourceforge.io/ACBrMonitor/Impressao.html * Expandir dados adicionais automático * Imprime continuação dados adicionais primeira página

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

Boa tarde, Qual o motivo da mudança? O MOC instrui a preencher somente EXTERIOR. Caso tenha alguma documentação ou NT com algo diferente disso, favor anexar para análise.

Tem que ser o pfx mesmo, com chave exportada. Parece ser erro no certificado ou senha

Tem ambiente gráfico no seu cenário?Se tiver, teste a URL no navegador para ver se está acessível. Teste um ping. https://hom1.nfe.fazenda.gov.br/NFeDistribuicaoDFe/NFeDistribuicaoDFe.asmx Confirme se não existe nenhuma restrição de internet, se a comunicação está liberada.

Boa noite Léo, Isso que eu queria confirmar, se não havia algum problema com o código. Tendo funcionado o mesmo código em outro ambiente, vamos caçar qual o problema no ambiente. Perfeito, vou verificar com os colegas se alguém consegue simular este cenário no Linux. Enquanto isso, seguem mais sugestões de testes. 1. Vi que aumentou o timeout, descartamos esta hipótese 2. Seu PathSchemas está apontando para unidade com letra, está correto assim para o Linux? PathSchemas=D:\INTERSOLID\ERP-CLOUD\erp-cloud-ms\TESTEACBR\assets\acbr\schemas 3. Analisando o log, métodos que não interagem com o certificado funcionam, provavelmente ainda temos algum problema com relação a dependências ou certificado. 3.1. Veja permissões de acesso ao certificado, tente atribuir acesso total ao caminho e ao arquivo. 3.2. Veja a solução do tópico a seguir, se faz sentido no seu cenário e se seguindo esses passos tem alguma mudança no resultado. Note que além da OpenSSL, tem que verificar a instalação da LibXml2.

Mais uma coisa, tente configurar o timeout para 30k ou mais, pois a comunicação pode estar sendo derrubada no meio, gerando a exceção.

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

Infelizmente não consegui montar um ambiente com seu exemplo. Não tenho conhecimento profundo da linguagem e precisaria de um exemplo básico para tentar simular o problema. Por favor, tente fazer um teste com o demo que temos no projeto( lib_test_teste-acbrlibnfe.js ) adicionando somente o método da Distribuição. Caso consiga reproduzir o erro com este demo, por favor, anexe o arquivo com seus ajustes para tentarmos simular aqui também.

Boa tarde, Se está consultando e acusando que foi transmitido, mas não consta no eCac, deve ser instabilidade no ambiente deles, devido ao volume de transmissões.

Boa tarde, Pode anexar o código simplificado para tentarmos simular aqui?

Buenas, Para quem quiser se aventurar no node.js, montei um ambiente de testes com os passos a seguir e funcionou corretamente com o ACBrLibCep, utilizando o demo dos fontes 1. Instalações seguindo o video a seguir: 1.1. Instalar o node: https://nodejs.org/en/download/ 1.2. Se não tiver o VSCode, instalar: https://code.visualstudio.com/download * Achei interessante usar o VSCode, conforme indicado no vídeo, pois e debug funcionou perfeitamente 2. Pacotes * Não instalar pelo terminal do VSCode, para mim apresentou erros, pelo prompt ou powershell funcionou corretamente 2.1. Para funcionar o ACBrLibCep, com o demo que consta nos fontes, instalar os pacotes a seguir npm install --save ffi npm install --save ffi-napi

Boa tarde, Confirme se está gerando registros do mês 09/2023, pois os registros de 10/2023 devem ser enviados no próximo mês.

Boa tarde Anderson, Obrigado por reportar, sua análise está correta, o tls1.3 funcionou porque o componente tratou como lt_all. O @Victor H. Gonzales - Panda já mandou uma correção para o svn. Voltando ao problema... O próprio Panda nos alertou que o Reinf não aceita o tls1.3. Indiquei o uso, imaginando que funcionasse, devido ao outro tópico que foi testado com sucesso, mas como já sabemos funcionou como lt_all. Como o Reinf só suportará o tls1.2 em 21/10/2023, precisa tentar verificar com quem distribui esse A3, que não está funcionando com tls1.2 ou com a própria sefaz, qual é o problema.

async getFinalResponse(length: number): Promise<IResponse> { return new Promise((resolve, reject) => { const aloc_sResposta = Buffer.alloc(length); const aloc_esTamanho = ref.alloc(ref.types.int, length); Na getFinalResponse permanece a aloc_sResposta como const, talvez seja o problema. Se não resolver mudando a constante acima, como ajustando automaticamente o tamanho do buffer permaneceu o problema, acredito que seja a hora de dar um passo para trás. Consegue fazer um exemplo bem enxuto, somente com o básico para a comunicação? Você tem algum outro método funcionando nesta lib? Se tiver, tente fazer um bem enxuto também para compararmos o que funciona com o que está com erro.

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

Boa tarde, Veja este tópico. Use tls1.3 onde não funcionar com 1.2. Esse problema de certificado A3 com DFes é recorrente, já houveram relatos de problemas com NFe, NFCe, CTe, inclusive um dos casos no ano passado a Sefaz assumiu problema do lado deles, mas não deram solução. Obs: casos anteriores também funcionavam com outros DFes no mesmo ambiente.

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.

Mais uma coisa, a declaração da variável não deveria ser "var", "string", etc? Em tese uma constante não receberia um retorno.

Boa tarde, O XML de retorno pode ser maior ainda, 6, 7, 8k. Para efeito de testes, tente valores maiores, exemplo 16k e veja se resolve. Outro teste, tente passar o ultNSU errado, o método vai retornar um XML pequeno e descartamos a hipótese do buffer se permanecer o problema.