Fabrício G. Araújo

@willismartins, se você já tem tratamento de contingência offline, basta adicionar mais esse código ao seu tratamento. Um resuminho (não funcional) de como mais ou menos trato a contingência offline no meu sistema é como isso aqui: try ACBrNFe.Enviar(... except on E: Exception do begin if (Pos('12007', E.Message) > 0) or // erro de conexão (Pos('12002', E.Message) > 0) or // timeout (Pos('12029', E.Message) > 0) or // limite de tempo de conexão (Pos('11004', E.Message) > 0) or // Equivalente: erro de conexão (Pos('10060', E.Message) > 0) or // Equivalente: timeout (Pos('ERRO NAO CATALOGADO', UpperCase(E.Message)) > 0) then begin ACBrNFe.NotasFiscais.Items[0].NFe.Ide.tpEmis := teOffLine; ACBrNFe.NotasFiscais.Items[0].NFe.Ide.xJust := 'PROBLEMAS TECNICOS NO ENVIO DA NFC-E'; ACBrNFe.NotasFiscais.Items[0].NFe.Ide.dhCont := Now; ACBrNFe.NotasFiscais.GerarNFe; ACBrNFe.NotasFiscais.Assinar; ACBrNFe.NotasFiscais.Validar; end; end;

@willismartins, minha referência foi essa aqui: Então acrescentei esse código (11004) que dá com OpenSSL, só que sem o espaço e tracinho citado pelo Régys do post acima.

Sim, realmente já percebi essa diferença quando desativa a rede, com WinCrypt (e a antiga Capicom) dá o erro 12007 e com OpenSSL dá o erro 11004. No meu caso adicionei mais esse código para tratar a questão de Contingência Offline... e bola pra frente.

Entendo, mas aí vai da interpretação de cada um. Legal disponibilizar esse recurso, pois quem quiser utilizar, está disponível. E também entendo a pressão que temos de nossos clientes para colocar do jeito que eles querem. Por exemplo, já vi DANFE com os dados do TEF acima do Qr-Code, que pelas NT não seria possível, e sim ao final. Mas quem irá fiscalizar né... é meio que uma terra sem lei, cada uma faz o DANFE que deseja mesmo.

Hum... só uma dúvida... e isso é permitido? Está de acordo com as notas técnicas?

Valeu @Daniel Simoes, vou estudar o funcionamento dele, mas já explicou bastante. Fui usuário SAC por um tempinho, mas agora não sou mais, na época a minha contingência estava funcionando bem legal e nem cheguei a ver o vídeo, mas de qualquer forma agradeço a dica.

Ué... nunca usei esse cara não Daniel. Sempre utilizei try...except e então verifico os códigos que assumo a contingência. Como funciona exatamente esse OnTransmitError, se dispará-lo já assumiria a contingência sem verificação de códigos?

Hum... também migrei para OpenSSL os clientes que possuem certificado A1 (antes utilizava Capicom, para A3 fui para WinCrypt), e os clientes começaram a reclamar que quando estão sem internet o sistema parou de entrar em Contingência Offline, pois o tratava em meu sistema os erros: 12007, 12002, 12029 para assumir a Contingência... percebi que também está retornando o erro 10060 com OpenSSL, então vou acrescentar mais esse erro para assumir a entrada em Contingência Offline em meu sistema.

Para NFC-e vale isso aqui @Gr@c@: fonte: http://www.nfce.se.gov.br/portal/painelMonitor.jsp Os outros estados tem seu próprio ambiente: Ah, e lá no Maranhão já tenho clientes utilizando a muito tempo a NFC-e 4.00, há uns 2 ou 3 meses, tudo ok.

Acredito que as URLs foram ajustadas em produção, mas só entram em vigor dia 17/07, conforme: http://www.nfe.ms.gov.br/a-sefaz-ms-informa-que-ocorrera-em-10-07-2018-proxima-terca-feira-alteracao-das-urls-da-versao-4-00-do-ambiente-de-producao-da-nf-e/

Imagino sim que o problema são as permissões, só não consegui fazer funcionar pela letra mapeada. Já vi problemas com servidor Win8.1 e terminal Win8.1, até situações que não recomendo como servidor Win7 e terminal Win10. Mas como disse, não entendi bem o porque de não funcionar, pois o usuário logado nos computadores é o mesmo com acesso total à pasta e ao compartilhamento... fazer o quê... coisas de Windows. Por enquanto fico na mesma, vou ter que colocar a pasta Schemas em drive local na máquina. Valeu por tentar ajudar. Sim Felipe, esse é o tópico que tomei conhecimento e citei com o "probleminha" que tem o componente com essas configurações... só não queria partir para essa solução de ter a pasta localmente, pois gera mais trabalho para o suporte. Mas fazer o quê, quando não funcionar a letra mapeada, vou ter que ter a pasta localmente. Valeu por tentar ajudar.

Olá pessoal, Sei que tem um "probleminha" no componente para acessar a pasta Schemas, e tenho que seguir o padrão de mapear a unidade de rede nos terminais, que só tem atalho da minha aplicação, para que funcione normalmente as opções com WinCrypt (com SSLXmlSignLib: xsLibXml2) e OpenSSL (com SSLXmlSignLib: xsXmlSec). Tenho feito isso e tem funcionado muito bem no Win7, mas estão surgindo vários clientes, com Win10 e Win8.1, que mesmo que esteja logado com o mesmo usuário nas máquinas, a pasta e o compartilhamento está total para o mesmo usuário, simplesmente não funciona nos terminais, dando o erro "the schema itself is not valid". Já sei que se apontar para uma pasta fixa local, funciona perfeitamente, mas não queria partir para essa solução. Então pergunto aos colegas, o que mais posso tentar com a letra mapeada para que funcione? Estou sem ideias.

Olha só, relutei, relutei, mas acabei acatando a sugestão do Daniel Simões de utilizar preferencialmente o certificado A1, então para todos o meus clientes que tem A1 a solução que não precisa de nenhuma dependência do Windows (funciona até no XP) estar ou não atualizado ou configurações do IE... é de loge a melhor solução, para isso foi utilizado a solução com OpenSSL com MinGW (com todas suas dlls específicas). Já para os clientes com A3, já encontrei de tudo, máquinas que funcionam e máquinas mesmo 100% atualizadas que não funcionam, já aí só temos a opção de utilizar a WinCrypt ou a finada Capicom, tenho optado pela WinCrypt, para não depender das configurações do IE, mas como falei, pode ser que nem com mágica funciona em alguns computadores, ainda mais com os Windows piratas dos clientes... infelizmente nesse caso tenho indicada uma possível formatação da máquina ou aquisição do certificado A1. Mas no geral tem funcionado ao atualizar 100% o Windows na maioria dos casos, mas sempre tem as exceções como falei. Boa sorte pessoal.

No meu sistema, caso aconteça a questão da duplicidade, como aconteceu com você, já envio uma tentativa de consulta e se estiver tudo ok, ou seja, inclusive com digest value ok, o usuário nem fica sabendo o que ocorreu, como se estivesse autorizado de primeira. Assim armazeno tudo direitinho com os protocolos de autorização e tudo e emito o DANFE. Mas a única diferença é que não utilizo o ACBrMonitor, utilizo os componentes mesmo, mas acredito que a lógica seria a mesma para ser tratada na sua aplicação.

Realmente @Gr@c@, não sei de onde tirei que se informasse o tPag = 03 ou 04 teria que ter a tag do card e consequentemente a tag tpIntegra, mas confesso que nunca testei autorizar como tiNaoInformado. Também acredito que tpIntegra = 1 seja para TEF, que atualmente não disponibilizo no meu sistema com NFC-e ou NF-e, só POS. Mas caso continue a ocorrer a restrição e não funcione para mim a opção tpIntegra = tiNaoInformado, não pensaria duas vezes em disponibilizar para o cliente uma telinha para informar os dados e assim passaria tpIntegra = 1 com todos os dados (mesmo não sendo TEF). Vou esperar para ver. Associei o fato dessa resolução ao meu problema, mas por enquanto NFC-e está passando tudo normal. Obrigado pelas informações, inté.

@Fr. Silva e @Gr@c@, o sistema de vocês já trabalha informando o tpIntegra = 1? E informando os demais dados, como CNPJ da credenciadora do cartão, além do tBand e cAut? Ah, só lembrando que a restrição ocorreu em produção com NF-e, segundo o cliente a NFC-e em produção está normal (menos pior).

Pessoal, não sei ao certo se tem relação com essa resolução, mas o meu sistema sempre foi informado os dados do pagamento do cartão como não integrado (tpIntegra = 2) e hoje apareceu um cliente dando a seguinte restrição: "Pagamento com cartao de credito em sistema de automacao nao integrado" Acredito que no MA alteraram as regras de validação em Produção. Especificamente a rejeição ocorreu em uma NF-e em Produção, vou tentar entrar em contato novamente com o cliente para saber se com NFC-e se ainda continua normal. PS - Pelo menos no dia 05/06 o ambiente de homologação de NFC-e no MA estava aceitando normal o tpIntegra = 2.

Realmente o ambiente de Homologação em GO v. 4.00 simplesmente não funciona com OpenSSL (também estou usando MinGW), então tive que efetuar testes (Homologação) com o certificado A1 de um cliente do MA, e então disponibilizei meu sistema em Produção para os clientes de GO e tem funcionado normalmente.

Pessoal, desconsiderem o post, na verdade o erro estava em minha aplicação, onde já chegava com os caracteres bugados quando ia chamar o método ACBrEcf.LinhaRelatorioGerencial.

Olá pessoal, Estou utilizando o componente ACBrECF, e estou com problemas com acentuação com minha Daruma FS600 no Relatório Gerencial. Pesquisei e vi em alguns posts a questão da Página de Código do componente, verifiquei no passo a passo, e está sendo mantido o defaul de 28591. O que mais posso testar para funcionar normalmente? Lembrando que com o uso da DarumaFramework.dll funciona normalmente. Qualquer ajuda será bem vinda, obrigado.

Em Goiás também foi estipulado prazos para encerramento do uso de ECFs, foram por etapas tipo Postos de Combustíveis um prazo, empresas do regime normal outro, até englobarem todas as empresas do estado com o prazo final em DEZ/17, ou seja, nesse ano de 2018 só é permitido NFC-e, portanto aqui, em GO, não permitiram o uso de ECF até o fim da memória não, mas cada estado pode estipular suas leis.

Obrigado por responder @José M. S. Junior. Ok, as configurações que me sugeriu são para especificamente MinGW, essa entendi bem, vou aplicá-las dessa forma. O que ainda não consegui entender direito com a WinCrypt e LibXml2, é que parece que a LibXml2 usa boa parte de dlls da OpenSSL, meio que tem uma dependência, é isso mesmo? Em outras palavras, a melhor forma de usar essa configuração abaixo: 1 - WinCrypt: SSLCryptLib = cryWinCrypt; SSLHttpLib = httpWinHttp; SSLXmlSignLib = xsLibXml2; Seria: {$DEFINE DFE_SEM_OPENSSL} {$DEFINE DFE_SEM_XMLSEC} {.$DEFINE DFE_SEM_LIBXML2} {$DEFINE DFE_SEM_CAPICOM} {$DEFINE DFE_SEM_MSXML} {$DEFINE DFE_SEM_INDY} {.$DEFINE USE_MINGW} Outra coisa, quando fiz uma distribuição do meu sistema com as diretivas default, ou seja, sem alterar nada, ao subir minha aplicação tinha a dependência da MSVCR120.dll, não entendi muito bem o porquê.

Olá pessoal, Utilizo o componente TACBrNFe, sei que é possível alterar no ACBr.inc as diretivas de compilação para deixar mais "enxuta" a aplicação em relação as dependências de dlls, confesso que fico meio confuso em relação a algumas dependências, até assisti ao vídeo que explica direitinho, mas ainda estou meio inseguro. O meu interesse é distribuir a minha aplicação com duas compilações bem definidas, uma para uso com certificados A3 com WinCrypt e outra com certificados A1 com OpenSSL. Sabendo que possuímos as seguintes diretivas: {.$DEFINE DFE_SEM_OPENSSL} {.$DEFINE DFE_SEM_XMLSEC} {.$DEFINE DFE_SEM_LIBXML2} {.$DEFINE DFE_SEM_CAPICOM} {.$DEFINE DFE_SEM_MSXML} {.$DEFINE DFE_SEM_INDY} {.$DEFINE USE_MINGW} Qual seria a melhor configuração das diretivas para essas duas situações de configuração do componente, sendo: 1 - WinCrypt: SSLCryptLib = cryWinCrypt; SSLHttpLib = httpWinHttp; SSLXmlSignLib = xsLibXml2; 2 - OpenSSL (com MinGW): SSLCryptLib = cryOpenSSL; SSLHttpLib = httpOpenSSL; SSLXmlSignLib = xsXmlSec; Agradeço desde já.

Isso mesmo @claudiomiguelmuller, conforme está na NT_2016_002_v1 51: Em relação a NFC-e, os prazos previstos são: - Desativação do versão 3.10 do leiaute da NFC-e: 01/10/2018; - Layout do QR-Code (tag: qrCode, Id:ZX02), versão “2.00”: - Ambiente de Homologação: 04/06/2018 (aceita NFC-e na versão 4.00 com o leiaute do QR-Code na versão “1.00” e versão “2.00”); - Ambiente de Produção: 02/07/2018 (aceita NFC-e na versão 4.00 com o leiaute do QR-Code na versão “1.00” e versão “2.00”); - Desativação da versão “1.00” do QR-Code em produção: 01/10/2018.

Me lembro que testei a 1 mês atrás e em MT ainda não estava disponível a NFC-e 4.00 em produção, mas em outros estados como GO e MA que já testei e está emitindo normalmente em produção NFC-e 4.00. Na prática todos os estados que possuem NFC-e já eram para estar emitindo desde DEZ/17, só MT que pelo jeito não conseguiram se adequar e aproveitaram os novos prazos para o Qr-Code 2.0 e até hoje não disponibilizaram... é complicado quando nem as SEFAZ cumprem os prazos definidos pelo governo... mas nós temos que cumprir né, fazer o quê.