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).

Estamos com este mesmo problema na SEFAZ/RS, usando (no Linux) "openssl 1.0.2g 01 Mar 2016". Rodando um "openssl ciphers -v" no console aparecem várias linhas contendo "TLSv1.2". Sabem se houve alguma novidade em relação a isso hoje?

Aqui no Ubuntu demorou mais de 1 minuto... [18:07:17] Gerando XML... Enviando para a SEFAZ... [18:08:32] Exception: Erro Interno: 1 Erro HTTP: 500 E minhas configurações estão assim: Geral.SSLCryptLib := cryOpenSSL; Geral.SSLHttpLib := httpOpenSSL; Geral.SSLLib := libOpenSSL; Geral.SSLXmlSignLib := xsXmlSec; WebServices.Tentativas := 1; WebServices.TimeOut := 2000; Alguma sugestão?

Esse vídeo acima se aplica para o Linux?

Conseguimos emitir NFe 4.0 em homologação no Linux 64, a questão do SOAP ACTION era um ve310 hardcoded esquecido na hora de enviar (por isso o Status funcionava). Foi necessário fazer uma conhecida alteração no tiposBasico_v4.00.xsd para funcionar: $ svn diff tiposBasico_v4.00.xsd Index: tiposBasico_v4.00.xsd =================================================================== --- tiposBasico_v4.00.xsd (revisão 13858) +++ tiposBasico_v4.00.xsd (cópia de trabalho) @@ -503,7 +503,7 @@ </xs:annotation> <xs:restriction base="xs:string"> <xs:whiteSpace value="preserve"/> - <xs:pattern value="[!-ÿ]{1}[ -ÿ]{0,}[!-ÿ]{1}|[!-ÿ]{1}"/> + <xs:pattern value="[!-ÿ]{1}[ -ÿ]*[!-ÿ]{1}|[!-ÿ]{1}"/> </xs:restriction> </xs:simpleType> <xs:simpleType name="TData"> $

Estou usando o SVN da URL svn://svn.code.sf.net/p/acbr/code/trunk2: alex@desktop-alex:~/fontes/ACBr$ svn update Atualizando '.': Na revisão 13858. alex@desktop-alex:~/fontes/ACBr$ Atualmente tenho apenas os seguintes arquivos modificados localmente: alex@desktop-alex:~/fontes/ACBr$ svn -q status M Exemplos/ACBrDFe/ACBrNFe/Lazarus/ACBrNFE_Demo.lpi M Exemplos/ACBrDFe/ACBrNFe/Lazarus/ACBrNFE_Demo.lps M Exemplos/ACBrDFe/ACBrNFe/Lazarus/Unit1.lfm M Fontes/ACBrDFe/ACBrDFeHttpOpenSSL.pas alex@desktop-alex:~/fontes/ACBr Da pasta Fontes o único que modifiquei foi para incluir os debugs que mencionei anteriormente: alex@desktop-alex:~/fontes/ACBr$ svn diff Fontes/ACBrDFe/ACBrDFeHttpOpenSSL.pas Index: Fontes/ACBrDFe/ACBrDFeHttpOpenSSL.pas =================================================================== --- Fontes/ACBrDFe/ACBrDFeHttpOpenSSL.pas (revisão 13858) +++ Fontes/ACBrDFe/ACBrDFeHttpOpenSSL.pas (cópia de trabalho) @@ -117,12 +117,14 @@ WriteStrToStream(FHTTP.Document, AnsiString(ConteudoXML)) ; // DEBUG // - //FHTTP.Document.SaveToFile( 'c:\temp\HttpSendDocument.xml' ); - //FHTTP.Headers.SaveToFile( 'c:\temp\HttpSendHeader.xml' ); + FHTTP.Document.SaveToFile( '/tmp/HttpSendDocument.xml' ); + FHTTP.Headers.SaveToFile( '/tmp/HttpSendHeader.xml' ); // Transmitindo // OK := FHTTP.HTTPMethod('POST', AURL); + FHTTP.Document.SaveToFile('/tmp/ReqResp.xml'); + // Verifica se o ResultCode �: 200 OK; 201 Created; 202 Accepted // https://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html OK := OK and (FHTTP.ResultCode in [200, 201, 202]); alex@desktop-alex:~/fontes/ACBr$

Descomentei os DEBUGs na "TDFeHttpOpenSSL.Enviar" e apareceu o seguinte: cat /tmp/HttpSendHeader.xml SOAPAction: "http://www.portalfiscal.inf.br/nfe/wsdl/NfeAutorizacao" Isso está correto? Talvez esteja aí o problema, pois o erro reclama a falta de um "soap action" válido: cat /tmp/ReqResp.xml <?xml version="1.0" encoding="utf-8"?> <soap:Envelope xmlns:soap="http://www.w3.org/2003/05/soap-envelope" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema"> <soap:Body> <soap:Fault> <soap:Code> <soap:Value>soap:Sender</soap:Value> </soap:Code> <soap:Reason> <soap:Text xml:lang="en">Unable to handle request without a valid action parameter. Please supply a valid soap action.</soap:Text> </soap:Reason> <soap:Detail /> </soap:Fault> </soap:Body> </soap:Envelope>

Alguém está conseguindo emitir NFe/NFCe 4.0 usando Linux 64 bits? Estou com o mesmo problema, o "NFeStatusServico4" funciona porém na hora de enviar continua dando erro 500. <?xml version="1.0" encoding="utf-8"?><soap:Envelope xmlns:soap="http://www.w3.org/2003/05/soap-envelope" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema"><soap:Body><nfeResultMsg xmlns="http://www.portalfiscal.inf.br/nfe/wsdl/NFeStatusServico4"><retConsStatServ versao="4.00" xmlns="http://www.portalfiscal.inf.br/nfe"><tpAmb>2</tpAmb><verAplic>RS201707181025</verAplic><cStat>107</cStat><xMotivo>Servico em Operacao</xMotivo><cUF>43</cUF><dhRecbto>2017-09-11T12:15:43-03:00</dhRecbto><tMed>1</tMed></retConsStatServ></nfeResultMsg></soap:Body></soap:Envelope>

Acho que deveria haver uma opção "ImprimirObsCont" com default false.

Mas estou usando a revision 13717. Houve alguma outra alteração no SOAPACTION do RS depois da revision 13678? alexsander@desktop-alex:~/fontes/ACBr/Fontes/ACBrDFe/ACBrNFe$ svn -r 13570:HEAD log ACBrNFeWebServices.pas ------------------------------------------------------------------------ r13571 | anfm | 2017-07-13 09:11:55 -0300 (Qui, 13 Jul 2017) | 1 linha Correção enviada no post http://www.projetoacbr.com.br/forum/topic/37538-status-nfe-40-erro/?do=findComment&comment=247478 ------------------------------------------------------------------------ r13576 | anfm | 2017-07-13 15:35:10 -0300 (Qui, 13 Jul 2017) | 1 linha Ajuste para permitir o funcionamento da versão 4.0 nos servidores da Bahia. Propriedade ACBrNFe1.SSL.SSLType deve ser configurada conforme cada estado, na teoria todos deveriam aceitar LT_TLSv1_2. ------------------------------------------------------------------------ r13590 | juliomar | 2017-07-15 21:50:08 -0300 (Sáb, 15 Jul 2017) | 2 linhas Correção do SoapAction do RS http://www.projetoacbr.com.br/forum/topic/37538-status-nfe-40-erro/?do=findComment&comment=247849 ------------------------------------------------------------------------ r13665 | anfm | 2017-07-27 09:40:35 -0300 (Qui, 27 Jul 2017) | 1 linha Correção citada em http://www.projetoacbr.com.br/forum/topic/37538-status-nfe-40-erro/?do=findComment&comment=249110 ------------------------------------------------------------------------ r13678 | dopi | 2017-07-28 19:29:26 -0300 (Sex, 28 Jul 2017) | 1 linha http://www.projetoacbr.com.br/forum/topic/37538-status-nfe-40-erro/?do=findComment&comment=249148 ------------------------------------------------------------------------ alexsander@desktop-alex:~/fontes/ACBr/Fontes/ACBrDFe/ACBrNFe$

Em resumo, a posição oficial seria "espere pela versão 4.00", é isso?