Fabrício G. Araújo

Bingo... agradeço d+ a ajuda de vocês @BigWings e @Johnny Benvenutti 2, funcionou de boa agora. Com a dica do BigWings e a url do Johnny com o xml dele de exemplo, finalmente abriu minha mente para enxergar a manezada que estava fazendo, pois estava bitolado na url do Qr-Code, sendo que o que está errado era da consulta 2.0. Johnny, você já está usando em produção o Qr-Code 2.0 também? Eu não tenho como testar por enquanto em produção, mas caso você já tenha testado e tenha as urls que estão funcionando, poderia me passar que então gero um novo ACBrNFeServicos.ini para os moderadores subirem para o repositório e assim beneficiar outros usuário com as urls corretas para GO.

Obrigado por tentar ajudar @Johnny Benvenutti 2, mas infelizmente não funcionou, fiz os seguintes testes em homologação: Teste 1: URL-QRCode=www.nfce.go.gov.br/post/ver/214413/consulta-nfc-e-homologacao Erro: 1824 - Element '{http://www.portalfiscal.inf.br/nfe}qrCode': 'www.nfce.go.gov.br/post/ver/214413/consulta-nfc-e-homologacao?chNFe=52180704429915000178650010000010251000029148&nVersao=100&tpAmb=2&dhEmi=323031382D30372D33315431313A32373A32352D30333A3030&vNF=18.81&vICMS=0.00&digVal=4E644B43637A50457231747564523951385A72566E644D653147673D&cIdToken=000001&cHashQRCode=065DC93C8D24B4E23CD50F9F7FEC87A673BA8853' is not a valid value of the local atomic type. Teste 2: URL-QRCode=http://www.nfce.go.gov.br/post/ver/214413/consulta-nfc-e-homologacao Rejeição: Endereço do site da UF da Consulta via QRCode diverge do previsto Teste 3: URL-QRCode=https://www.nfce.go.gov.br/post/ver/214413/consulta-nfc-e-homologacao Rejeição: Endereço do site da UF da Consulta via QRCode diverge do previsto Você conseguiu utilizar no seu ambiente de homologação normalmente? Qualquer sugestão será bem vinda.

Pessoal, Alguém já tentou emitir em homologação a NFC-e 4.00 com Qr-Code 2.0 em GO? Já efetuei testes no ambiente de homologação no MA e funcionou de boa, mas em GO só da: "Rejeição: Endereço do site da UF da Consulta por chave de acesso diverge do previsto". As urls (e .res) estão atualizadas e tudo mais. Alguém que tenha conseguido em GO e que tenha a informação privilegiada das urls que estão funcionando, e que possa compartilhar com a comunidade?

Onde você diz no post acima, você copiou essa url do seu sistema ou só digitou na postagem mesmo? Pois nessa url está faltando o "r" de virtual. E outra coisa, a questão de usar urls diferentes, não é simplesmente a configuração dos seus ambientes que estão diferentes. Tipo a Forma de Emissão em um ambiente está normal e outro está ativado algum tipo de contingência para NF-e, não seria isso?

@willismartins, continue no mesmo tópico inicial, não fique criando vários tópicos sobre o mesmo assunto:

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

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.