Fabrício G. Araújo

Hum... nunca atentei para esse fato, mas sim uso um contador, outras pessoas geram valores aleatórios para não ficar fácil identificar a chave (que imagino seja o mais correto). Com certeza quando meu contador chegar em algum daqueles números dará m... Mas não fiz nada para tratar isso por enquanto. Até porque no seguimento que atuo até chegar em algum daqueles números já terei aposentado.

Olha o protocolo da nota que acabei de enviar tudo ok: @Sandro TC, você não está obedecendo essa regra:

@Sandro TC, acabei de testar agora e está tudo normal. Talvez a SEFAZ/GO passou a validar o código numérico e agora você não está conseguindo emitir as notas. Como sempre gerei corretamente nunca tive esse tipo de problema.

@ifaster, acabei de validar novamente e o ambiente de homologação em GO está tudo ok. Se for o caso, criar um novo tópico, mas olhei o seu xml e você está gerando incorretamente, a mensagem de restrição está correta, realmente o valor do seu produto não confere com os totais da nota.

Desculpe a grande demora @Daniel Simoes, Infelizmente não é mais possível reproduzir o problema com a SEFAZ/GO em homologação. Resolvi testar hoje, pois o ambiente de homologação ficou com problemas ontem, e hoje tinha voltado a dar o erro 10091, só que com os meus fontes modificados enviando o .pem, que já estava funcionando normalmente. Então aproveitei e resolvi reproduzir o erro original, não enviando o .pem, só que para minha surpresa, voltou a funcionar, com o executável original da época... ou seja, o ambiente de homologação de GO foi modificado, não sendo possível mais reproduzir o erro original, para depois testar as suas modificações. Agora vou ficar atento, se por ventura, algum dia volte a ter problemas em produção, que até o momento está tudo ok, então terei as possibilidades de testes.

Olá pessoal, Passando por aqui só para informar que o ambiente de homologação NFC-e em GO voltou a funcionar... mas com uma ressalva, está funcionando apenas com Wincrypt, pois com OpenSSL (mingw) não está funcionando... vou fingir que nem vi isso... dá até arrepio no cabelo da nuca só de pensar a possibilidade de ocorrer algo nesse sentido em produção... torcer para que não.

Vi o tópico nos assinantes SAC, mas criei outro aqui para poder informar que o mesmo está acontecendo comigo no ambiente de homologação em GO para NFC-e. Simplesmente deu essa loucura na SEFAZ/GO. Ah, e só respondendo ao questionamento do @EMBarbosa, o meu lote está diferente assim como o cNF e nNF, e mesmo assim está ocorrendo a rejeição.

Mmmm... acho que foi só rata minha mesmo pessoal, pode desconsiderar o post. Não faz sentido algum uma venda para consumidor final informar esses campos, seria mais para os casos de devolução de compras, perdas ou outras coisas. Desculpa aí galera.

Pessoal, Estou verificando a documentação mais atual para os dados do registro ICMSSN500, onde temos: Mas acredito que tenha uma falha no componente para NFC-e, pois nunca irá gerar os campos vBCSTRet, pST, vICMSSubstituto e vICMSSTRet, conforme está codificado fixo para somente o modelo 55 (NF-e) e não disponível para o modelo 65 (NFC-e). Conforme os fontes em pcnNFeW: ... csosn500 : begin //10g if (nfe.Ide.indFinal <> cfConsumidorFinal) and (nfe.Ide.modelo = 55) then begin Gerador.wCampo(tcDe2, 'N26', 'vBCSTRet ', 01, 15, 1, nfe.Det[i].Imposto.ICMS.vBCSTRET, DSC_VBCSTRET); if (NFe.infNFe.Versao >= 4) then begin Gerador.wCampo(IIf(FUsar_tcDe4,tcDe4,tcDe2), 'N26.1', 'pST', 01, IIf(FUsar_tcDe4,07,05), 1, nfe.Det[i].Imposto.ICMS.pST, DSC_PST); // Algumas UF estão exigindo o campo abaixo preenchido mesmo quando for zero. Gerador.wCampo(tcDe2, 'N26b', 'vICMSSubstituto', 01, 15, OcorrenciasVICMSSubstituto, nfe.Det[i].Imposto.ICMS.vICMSSubstituto, DSC_VICMSSUBSTITUTO); end; Gerador.wCampo(tcDe2, 'N27', 'vICMSSTRet', 01, 15, 1, nfe.Det[i].Imposto.ICMS.vICMSSTRET, DSC_VICMSSTRET); end; ... Essa minha interpretação está correta? Existe realmente a falha?

Bom dia @Doni Delphi, Valeu por tentar ajudar, mas também tenho a cópia do fonte, inclusive já copiei ele e coloquei no dpr do meu projeto para voltar a compilar sem fazer mais nada. Só achei que teria algo com os fontes atuais que poderia substituir a rotina para que não precisasse fazer isso. Mas enfim, está funcionando e então vou deixar dessa forma. Mais uma vez obrigado, um ótimo dia.

Olá pessoal, Fiquei um bom tempo sem atualizar todo o Acbr, e possuo um Danfe próprio, só que quando atualizei, percebi que não existe mais a ACBrDFeQRCodeBar.pas, que ficava em (Acbr\Fontes\ACBrDFe), então dava uses nessa unit para gerar o código de barras da NF-e no Danfe da seguinte forma: uses ACBrDFeQRCodeBar; procedure TFormRelDANFE.SetBarCodeImage(ACode: String; QRImage: TQRImage); var b : TBarCode128c; begin b := TBarCode128c.Create; b.Code := ACode ; b.PaintCodeToCanvas( ACode, QRImage.Canvas, QRImage.ClientRect ); b.free; end; // Exemplos de chamadas no BeforePrint do QuickReport SetBarCodeImage(strChave, qriBarCode); ou SetBarCodeImage(strChaveContingencia, qriBarCodeContingencia); Então vem a pergunta, por qual unit posso substituir o código acima para continuar funcionando meu Danfe? Quem puder ajudar, agradeço muito.

@tania, parece que outras pessoas tiveram o mesmo problema que você e foi solucionado para eles, veja esse tópico:

Pessoal, ainda estou fazendo pesquisas e testes para ver se é possível fazer algo para que volte a funcionar em GO com OpenSSL os novos certificados. Dando um recapitulada, caso pegue um certificado A1 de um cliente em que está assim: Funciona normalmente o status serviço em Produção em GO, como o Demo, inclusive o cliente está emitindo normalmente com OpenSSL MinGW em nosso sistema. Já com outro certificado A1 mais novo, que está assim: NÃO funciona o status serviço em Produção em GO, como o Demo, esse cliente não funciona de jeito nenhum com OpenSSL MinGW, somente com Wincrypt (com httpWinHttp). Vale lembrar que todas as cadeias de certificados estão instaladas em minha máquina, tanto é que com Wincrypt funciona normalmente. Ah, só lembrando também do erro antigo em GO, que em Homologação nenhum dos certificados funciona em GO o status serviço com o Demo. ... Agora vem alguns questionamentos que talvez a comunidade e principalmente os moderadores possam ajudar nas pesquisas. 1 - Não entendo como funciona internamente a questão do funcionamento dos certificados, mas a suspeita é que com OpenSSL a cadeia de certificados não é enviada. Isso procede? 2 - O Wincrypt funciona pois envia junto as cadeias de certificados associadas? 3 - Se a suspeita 1 acima procede, suspeitamos que os servidores de GO em Homologação não possuem as cadeias instaladas, e em Produção só não possui as últimas cadeias instaladas, pois o certificado mais antigo funciona (Raiz Bras. v2 e Secr. RF v3) e o mais novo não (Raiz Bras. v5 e Secr. RF v4). Esse entendimento está correto? 4 - Agora vem a grande questão: É possível fazer alguma adaptação para que o OpenSSL MinGW envie a cadeia de certificados? Quem participou do desenvolvimento do projeto teria como dar algum direcionamento para que possamos tentar efetuar esse procedimento e se obter sucesso compartilhar com a comunidade? Desculpem pelo grande texto, mas ainda estou empenhado a achar uma solução para GO com OpenSSL MinGW, agradeço a todos que puderem contribuir.

Ainda bem que não tenho mais clientes com WinXP, fiz até um teste na época por curiosidade e até funcionou, mas mesmo assim fiz com que os clientes migrassem. Pois é... infelizmente não estou vendo outra saída... estou chegando a conclusão que pelo jeito em GO em produção (com alguns certificados A1, principalmente novos) não existe nenhuma solução que não dependa da atualização do Windows e/ou configurações do IE. Tinha migrado para OpenSSL justamente por não ter que passar pelo transtorno da atualização do Windows, dando uma solução imediata para o cliente na época. Desanimante uma coisa dessas... ? e sem saber o que está acontecendo. Obrigado por tentar ajudar.

Tenho vários clientes em produção utilizando OpenSSL com MinGW em GO sem problemas, agora estão atualizando os certificados que estão expirando e está parando de funcionar em seus ambientes (produção), dado o erro do título do tópico. Então peguei o problema para analisar e fiquei sem ter como testar (em homologação) com OpenSSL com MinGW, pois infelizmente em GO em homologação não funciona nem os certificados antigos e nem os novos. Sobre alterar para httpWinHttp, sei que não depende de configurações do IE, mas não tenho como fugir da atualização do Windows né?

Eita @BigWings, mesmo com outro certificado, que o cliente está emitindo normalmente em produção, o ambiente de homologação em GO dá o mesmo erro... agora me enrolei mesmo. Será que a questão do problema em homologação está refletindo em produção em GO? O chato é que só está acontecendo com os novos certificados... já não sei mais o que testar, mais alguma sugestão?

@BigWings, estou testando em homologação. Mas em GO em homologação só não funciona o StatusSevico, que nem uso, se enviar funcionava normalmente. Mas para desencargo de consciência vou ver se consigo outro certificado A1 de outro cliente e vou validar o ambiente em GO novamente. @Felipe E. Resende Mesquita, tinha visto exatamente essa dica sua em outro post, já tentei ela. Usei o instalador da VALID (utilizei esse que baixei agora InstaladorCadeias_1.0.2.0.exe), então instalei o certificado, exportei para arquivo pfx e nada. Inclusive para a exportação ainda utilizei essa dica aqui: https://suporte.contabilizei.com.br/hc/pt-br/articles/213827443-Como-exportar-o-seu-certificado-digital-A1-com-chave-privada

@Felipe E. Resende Mesquita, obrigado por tentar ajudar. Verifiquei todo o tópico, e novamente se enquadra em alterações de configuração com ou uso de OpenSSL com SSLHttpLib com httpWinINet (aí voltamos a ter dependência de atualização do Windows e config. do IE), ou outra sugestão foi deixar de utilizar a MinGW (que preferia manter, até para não dar conflito com outro sistema que por acaso utilizasse a openssl original, até porque as dlls da MinGW possui nomes diferentes e as mantenho junto do exe). Vale lembrar que tenho vários clientes em GO utilizando normalmente a solução OpenSSL com MinGW (inclusive com SSL.SSLType = LT_TLSv1_2), mas com a substituição do certificado estão parando de funcionar. É aquela estória... acredito que com certeza o problema está com o novo certificado, mas não sei o que é, fiz várias coisas como atualizar várias cadeias, instalar o certificado e exportar novamente para arquivo depois de instalar novas cadeias e nada de funcionar.

Até onde sei @Augusto Knirsch, com OpenSSL com MinGW funcionaria até no WinXP que nem sequer tem suporte a TLS 1.2, portanto não tem dependência do Windows. O duro é que em GO passou a ser obrigatório o uso de NFC-e no início do ano, então vários clientes adquiriram certificados A1 no fim do ano passado, que agora estarão renovando o certificado e estão começando a apresentar esse erro ao substituir o certificado.

Obrigado por tentar ajudar @Augusto Knirsch, mas não queria dar essa solução de modificar a configuração e ter a dependência do Windows atualizado, por isso queria identificar o que é necessário fazer para que continue funcionando com a OpenSSL com MinGW que funcionava antes normalmente.

Olá pessoal, Encontrei outros posts sobre esse assunto, mas nenhum deu uma solução satisfatória, pois muitos conseguiram fazer funcionar mudando a configuração para Wincrypt ou Capicom, mas não queria partir para essa solução, já que para certificados A1 com OpenSSL com MinGW, não tenho que me preocupar com atualizações do Windows, ou configurações do IE. O cenário que está ocorrendo o problema, é que o cliente estava utilizando o seu certificado A1 normalmente, emitindo NF-e / NFC-e 4.0, com OpenSSL com MinGW, então estava perto de expirar o seu certificado e então adquiriu um novo A1, e agora simplesmente não funciona com o novo certificado, dando o erro: Erro Interno: 10091 Erro HTTP: 500. As configurações utilizadas são de OpenSSL com MinGW: libOpenSSL: SSLCryptLib = cryOpenSSL; SSLHttpLib = httpOpenSSL; SSLXmlSignLib = xsXmlSec; As dlls ficam junto do meu executável, são as mesmas copiadas da pasta ACBr\DLLs\XMLSec\MinGW\32 O certificado é informado via diretório, apontando para o arquivo pfx. Esse cliente em específico é de GO e peguei o certificado dele e o mesmo ocorre em minha máquina. O que vocês sugerem pessoal? Porque parou de funcionar com a solução OpenSSL com MinGW? Quem puder ajudar, agradeço desde já.

Obrigado por tentar ajudar @Daniel Simoes. Perguntei da questão da USB mais por desencargo de consciência, pois sabia que com a Bematech não era possível via ACBrECF. Como o suporte da empresa está no meu pé por conta do "trabalhozinho" a mais de ter que instalar o emulador de porta e configurar novamente o sistema para porta COM, e então devido ao fato de ter (em alguns clientes) ficado mais lento, então o suporte está tentando achar um culpado, que para eles seria deixar de usar a USB diretamente, sendo que sei que não, que apenas tenho que identificar a melhor configuração para resolver o real problema que é a lentidão. A lentidão é a percepção do usuário ao emitir o cupom fiscal, o chato é que nem é possível ver presencialmente e constatar a questão da lentidão, pois somos de GO e praticamente só temos clientes em MG que ainda utilizam ECF. Infelizmente não é possível utilizar o ECFTeste, pois só ocorre em alguns cliente e então não poderia emitir cupons fiscais de testes com o ECFTeste, como disse antes, com a minha ECF de desenvolvimento Bematech 2100 TH FI, funciona normalmente, nada de lentidão. Um dos itens que posso verificar é questão da atualização dos drivers, vai que ajuda, obrigado pela dica. @Daniel Simoes, mas além disso, como você faz em seus sistemas em relação a que tipo de configuração utilizar por modelo de Bematech? Tipo em relação aquelas configurações de Baund Rate, Handshaking, ou outras, você tem uma pré-configuração para cada modelo (MP-2100/MP-4000...), ou disponibiliza em seu sistema para informar essas configurações manualmente, tipo na base de tentativa e erro, ou tem como saber a melhor configuração por modelo? Desculpa pelo textão, mas sem querer abusar da sua boa vontade, se puder passar mais alguma informação que possa ajudar, a ajuda sempre será bem vinda, e agradeço desde já.

Pessoal, Antes utilizada a dll da Bematech para comunicação com as ECF, até já tinha outros modelos de outros fabricantes já programado com uso do ACBrECF, então devido a migração de um Delphi mais antigo para o atual, decidimos migrar e unificar toda a programação para uso único do componente ACBrECF. Só que alguns clientes estão reclamando de lentidão na impressão que não ocorria antes. Seguem algumas perguntas se puderem me auxiliar: 1. Nas pesquisas que fiz, realmente não tem como configurar o ACBrECF para comunicação direta pela USB? Realmente a única opção é somente por emulação de porta COM? 2. Que configurações poderei testar para tentar resolver a questão da lentidão na impressão dos comandos? Tenho uma Bematech 2100 TH FI para desenvolvimento e não tive problema algum, funciona normalmente e super rápido, mas em alguns clientes ocorre a questão da lentidão e como não tem como utilizar o ECF dos clientes para teste fica difícil identificar algo. Quem puder ajudar com alguma dica, qualquer sugestão será bem vinda.

@jcdatrindade, Não uso o Monitor, mas sei que pelo Demo, com uso da WinCrypty, suporta tanto A1 como A3. Essa descrição no Monitor onde está: "Número de Série (Certificado A3)", seria melhor descrita se fosse algo do tipo "Número de Série (Certificado instalado A1 ou A3)". Portanto o que imagino que aconteceu com você, é que está utilizando o certificado A1 da matriz que você instalou, por isso está funcionando normalmente, ou seja, o número de série informado é o A1 da matriz. Não seria isso?

Nossa... não sabia disso @BigWings, muito obrigado pela informação, valeu d+.