Fabrício G. Araújo
-
Total de ítens
414 -
Registro em
-
Última visita
-
Days Won
2
Tipo de Conteúdo
Blocks
Notes ACBrLibNFe
Fóruns
Downloads
Calendário
Posts postados por Fabrício G. Araújo
-
-
Acredito que seja a mesma situação de MT mesmo, veja a postagem do Daniel S Ferreira:
O ideal seria entrar em contato com a SEFAZ/PR para questioná-los da falha da validação deles, pois não estão seguindo a especificação da NF.
-
@Iago de Assis, veja se você está configurando a NFC-e com a versão 4.00. Cheguei a receber exatamente esse erro quando por engano configurei como versão 3.10 e Qr-Code 2.0.
-
Significa que a própria SEFAZ/PR não está respeitando as especificações estipuladas na NT, ou seja, provavelmente terão que alterar a página deles para seguir a NT. Que canseira isso hein... parece que em outro estado tinha outro problema parecido com esse, se não me engano era o MT, eu acho.
-
@BigWings, caso queira disponibilizar no repositório o arquivo que funcionou, estou anexando nesta postagem:
-
1
-
-
Blz @Johnny Benvenutti 2, até tenho muitos clientes com NFC-e 4.00, mas com o Qr-Code original, assim como você, vou esperar um tempinho para ativar o Qr-Code 2.0.
E @BigWings... Então foi percebido que oficialmente (pelo menos por enquanto) a url de consulta do qr-code 2.0 em homologação não funciona para GO, não seria interessante atualizar o arquivo ACBrNFeServicos.ini para os demais desenvolvedores?
-
Acredito que não tenha que se preocupar @leotelles, se o seu sistema está gerando o Qr-Code certinho, e o que é lido dele retorna exatamente o conteúdo válido da tag <qrCode> do seu xml (a url com todos os parâmetros), então o que diz respeito a você está tudo ok, o restante é a SEFAZ correspondente é que terá que providenciar o direcionamento para a listagem da NFC-e, ou seja, a SEFAZ tem que implementar a página corretamente.
-
1
-
-
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.
-
Teste 1:
-
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?
-
Em 24/07/2018 at 13:27, Leao disse:
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.
-
12 minutos atrás, Aurino disse:
As NT's não informa que deve ser informado as bandeiras dos cartões mas também não diz que é proibido.
Porém, mantem a mesma regra, informar o meio de pagamento clara e segundo as regras NT's e Procons.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.
-
1 hora atrás, Daniel Simoes disse:
Porque não tratar erros de cm contingência off-line em OnTransmitError ?
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.
-
1
-
-
16 horas atrás, evandromira disse:
Após atualizar o acbr com as novas URLs MS estou com a mensagem
WebService Consulta Status serviço:
- Inativo ou Inoperante tente novamente.
Erro Interno: 12029
Erro HTTP: 0
URL: https://nfe.sefaz.ms.gov.br/ws/NFeStatusServico4
Falha no Envio da Requisição.
Erro: 12029 - Conexão com o Servidor falhouAlguma dica?
Acredito que as URLs foram ajustadas em produção, mas só entram em vigor dia 17/07, conforme:
-
1 hora atrás, Antonio Carlos L disse:
Oi Fabricio, o que você relata parece ser erro de permissões.
A pasta Schemas que segundo você esta em uma unidade de rede, ela esta em um SO servidor ( W2012, SMB Linux ) ou uma máquina com SO normal ?
Essa máquina é ligada ANTES de todas as demais que fazem uso desse recurso ?
A pasta esta com permissão de segurança para TODOS ?
São algumas perguntas
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.
41 minutos atrás, Felipe E. Resende Mesquita disse:Bom dia, Fabrício G. Araújo
Parece que existe uma limitação da libXml2 que não é compatível com UNC. O ideal seria colocar a pasta schemas localmente.
A informação está nesse tópico abaixo:
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.
-
1
-
-
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.
Erro Forma Pagamento NFE 4.0
em ACBrNFe
Postado · Editado por Fabrício G. Araújo
@Célio Rafael Martins Júnior, posta o trecho do seu código quando informa no componente a forma de pagamento, já vi aqui muitos darem mais de um Add e não perceberem.