Alexsander

Copiei e deu o mesmo erro, preciso renomear alguma DLL dessas? PS: Minha configuração está assim: Geral.SSLCryptLib := cryOpenSSL; Geral.SSLHttpLib := httpOpenSSL; Geral.SSLLib := libOpenSSL; Geral.SSLXmlSignLib := xsXmlSec; Geral.VersaoQRCode := veqr200;

Nosso PDV roda no Linux desde 2018 sem problemas, porém estamos com dificuldade pra fazer funcionar no Windows. Falha ao carregar biblioteca de Criptografia do XMLSec [openssl] Fiz um "svn update" e procurei na pasta "DLLs" tudo que continha "openssl": xxx@yyy:~/fontes/ACBr$ find . | grep dll | grep openssl ./DLLs/XMLSec/MinGW/32/libxmlsec1-openssl.dll ./DLLs/XMLSec/MinGW/64/libxmlsec1-openssl.dll ./DLLs/XMLSec/libxmlsec-openssl.dll Sem o arquivo "libxmlsec.dll" o aplicativo nem abre, mas ele parece não estar achando essa DLL com sufixo "openssl". Existe alguma lista "oficial" ou "recomendada" de DLL para emitir NFe no Windows? Pelo que vi no fórum ao longo dos anos isso mudou muito, de Capicom a OpenSSL, qual é a configuração ideal em 2022?

Parece mesmo ser um bug.

Aquela mensagem era de maio de 2017, atualmente estamos imprimindo com : ACBrNFe1.NotasFiscais.Items[0].Imprimir;

Procurei no SVN e não achei nada referente a isto no ACBrMonitorPLUS, alguém sabe se esta nova propriedade chegou a ser implementada?

Pelo que entendi o ACBrMonitorPLUS simplesmente não funciona no Windows Server 2008, é isso?

Retomando: este é o único problema que ainda está incomodando, mesmo dentro de um bloco try ... except a aplicação dá CRASH exatamente na chamada da Enviar ( ) após imprimir, via "GerarLog", a mensagem que mencionei acima. Pelo que pudemos observar isto só ocorre quando há uma queda de Internet e o cliente tem uma redundância 3G/4G com muita perda de pacotes; não chega a cair a Internet mas a perda é enorme. É bem difícil reproduzir, conseguimos um "Vivo Box" para testar e tivemos que deixar vários downloads simultâneos para simular a conexão.

Reconfiguramos aqui para a 3.10 por enquanto...

No Linux (Ubuntu 16.04 LTS 64-bits) ocorre o mesmo problema, também esporadicamente. Coloquei uma GerarLog e trava na seguinte mensagem: Inicio TNFeRecepcao Num cliente que emite mais de 10.000 cupons/dia ocorre umas 10 vezes por dia.

Quando enviei código para esta mesma classe ACBrETQ, em 2009 e 2010, tomei cuidado para não causar uma "breaking change"; se for possível ver no fórum ou SVN antigo vão ver que mantive valores padrões para as novas propriedades e procedures criadas de forma que os códigos existentes não parassem de funcionar. Por exemplo, ao incluir o parâmetro "SubFonte" na procedure "ImprimirTexto" lembro que coloquei um valor default na definição. Desta forma, os códigos que não passavam este parâmetro seguiram funcionando sem alterações. Não se trata de manter o que está errado mas sim de não quebrar o que está funcionando. Estou aqui tentando fazer uma crítica construtiva, consciente de que faz anos que não envio código para o ACBr. Seria interessante deixar o "jeito antigo" como default de alguma forma, sem forçar todo mundo a mudar um grande volume de seus códigos. Veja o quanto de suporte esta alteração gerou...

Acho temerário fazer uma "breaking change" como essa alterando um default. Talvez tivesse sido mais seguro usar uma Unidade "etqLegado" para funcionar como era antes e deixar como default. Confesso que não entendo o motivo desta alteração ter sido feita desta forma.

Vocês têm certeza que esta alteração está correta? Vou ter que retornar aqui ao jeito antigo, pois eu gravo o dígito junto com o NossoNumero no banco de dados. Na Remessa são gerados 8 dígitos (7 do RightStr + 1 do DigitoNossoNumero) Linha 705: PadLeft(RightStr(NossoNumero,7),7,'0') + DigitoNossoNumero + // 63 a 70 Agora, na versão que está no SVN, o Retorno passou a ler apenas 7 dígitos: Linha 1053: NossoNumero := Copy(Linha,63,07); Até os comentários estão corretos: eram 8 dígitos (do 63 ao 70). Tenho impressão que este "conserto" foi equivocado.

Ambiente: Linux 64 (Ubuntu 14.04 LTS) Um cliente tem caixas com Wi-Fi em uma de suas 19 lojas. Nesta loja (somente nesta loja), no caixa mais distante do roteador, tem ocorrido com frequência o seguinte erro (as linhas que começam com [ACBr] são impressas via evento OnGerarLog, as que tem o horário são impressas via DebugLn): [16:03:19] Enviando para a SEFAZ (1)... [ACBr] Inicio TNFeRecepcao [ACBr] ERRO: [ACBr] Erro Interno: 110 [ACBr] Erro HTTP: 0 [ACBr] ERRO: [ACBr] Inicio TNFeRetRecepcao [ACBr] Versão Layout: 3.10 [ACBr] Ambiente: 1 [ACBr] Versão Aplicativo: RSnfce201710241656 [ACBr] Recibo: [ACBr] Status Código: 215 [ACBr] Status Descrição: Rejeicao: Falha no schema XML [ACBr] UF: RS [ACBr] cMsg: 0 [ACBr] xMsg: [ACBr] ERRO: Rejeicao: Falha no schema XML [16:03:22] Retorno WS = <retConsReciNFe versao="3.10" xmlns="http://www.portalfiscal.inf.br/nfe"><tpAmb>1</tpAmb><verAplic>RSnfce201710241656</verAplic><nRec /><cStat>215</cStat><xMotivo>Rejeicao: Falha no schema XML</xMotivo><cUF>43</cUF><dhRecbto>2018-01-03T16:03:21-02:00</dhRecbto></retConsReciNFe> [215] Rejeicao: Falha no schema XML Este trecho de código tem apenas 3 linhas: DebugLn(), Enviar() do ACBr e DebugLn(). Na verdade o erro não é de schema, mas sim de "time out"; basta tentar enviar novamente o mesmo XML que funciona. No entanto esse Erro Interno 110 é "mascarado", e no RetornoWS vem esta rejeição 215. Alguma sugestão?

Tive um problema similar, tentei carregar o XML, alterar a chave e gravar novamente (para depois consultar na Sefaz) porém o ACBr cria uma TERCEIRA chave nova. Fora editar manualmente o XML, tem alguma maneira de "forçar" uma chave? Tentei mudar o cNF mas ele também acaba sendo ignorado. Tentei zerar o "XMLOriginal" porém a chave antiga (incorreta) é preservada.

Temos tido este problema de forma intermitente hoje (que é o dia em que supostamente deveria entrar a NFe 4.00).