Fabrício G. Araújo

Realmente ocorreu o erro de null em vários clientes de MT pela manhã, mas acredito que era alguma instabilidade na SEFAZ de MT, pois devia estar preparando para validar a regra do QR-CODE, que entraria em vigor dia 01/11/2016, depois parou de dar o erro do null e passou a dar a mensagem em alguns clientes do "464 - Código de Hash no QR-Code difere do calculado", mas isso porque simplesmente a clientela cadastrou incorretamente os dados do CSC, ao cadastrar corretamente tudo voltou ao normal.

Acredito que montar o XML na unha à partir do site, com a questão do captcha e tudo mais, não seria possível gerar um XML válido, até porque não teria como recriar a assinatura do Emitente, até onde lembro não consta essa informação lá, no máximo o digestValue com os dados da autorização. <editado> Ops, depois que vi que o @BigWings cita a questão do botão download do site, dessa forma baixaria sim o XML completo, a rotina acima é que um tempo atrás o pessoal baixava na unha analisando o HTML da página. Não entendo muito bem como funciona o download legal (com os webservices disponibilizados pelo governo), com toda aquela parada de manifesto daqui e dali para fazer o download, não tenho implementado isso no meu sistema e nem sequer estudei a fundo para entender esse processo. Mas conversando com representantes de empresas que fazem esse tipo de serviço, o pessoal me explicou que conseguem baixar normalmente todos os XMLs de uma empresa, com seu CNPJ e seu certificado, a única coisa que eles tem que tomar cuidado é com o uso indevido, que segundo eles, ao solicitar o download é fornecido um número máximo de XML que serão baixados, então após baixar, é necessário aguardar 1 hora e repetir o processo, que funciona normalmente sem dar uso indevido. Em fim, pelo menos foi isso que me passaram.

Esse outro assunto já foge do assunto do tópico, mas estou estudando isso justamente agora, pois não implementei contingência em meu sistema. Nas pesquisas separei alguns tópicos que achei interessantes que me esclareceram muito: Espero ter ajudado. Valeu.

Quando ela foi criada no Trunk2 ainda não era obrigatório a geração do QR-CODE, inclusive se gerasse na época, algumas SEFAZ rejeitavam, então por isso foi criada a propriedade.

Olá @licerio, Setou a propriedade ACBrNFe.Configuracoes.Geral.IncluirQRCodeXMLNFCe para True?

Olá @petry, Como disse antes, não sei se existe atualmente uma forma melhor de se gerar o QR-CODE, o fato é que para mim está funcionando. O código abaixo é o evento OnBeforePrint da banda do QuickReport que possui apenas um componente de imagem com o nome qriQRCode (tipo TQRImage): procedure TFormRelDANFE_Bobina_NFCe.qrbQRCodeBeforePrint(Sender: TQRCustomBand; var PrintBand: Boolean); var QRCodeBitmap: TBitmap; QRCode: TDelphiZXingQRCode; Row, Column: Integer; Scale: Double; cDest, sURL: String; begin QRCodeBitmap := TBitmap.Create; try QRCode := TDelphiZXingQRCode.Create; try if (FNFe.Dest.idEstrangeiro <> '') then cDest := FNFe.Dest.idEstrangeiro else cDest := FNFe.Dest.CNPJCPF; FACBrNFe.Configuracoes.Geral.IdCSC := FIdCSC; FACBrNFe.Configuracoes.Geral.CSC := FCSC; sURL := FACBrNFe.GetURLQRCode(FNFE.Ide.cUF, FNFe.Ide.tpAmb, Copy(FNFe.InfNFe.Id, 4, 44), cDest, FNFe.Ide.dEmi, FNFe.Total.ICMSTot.vNF, FNFe.Total.ICMSTot.vICMS, FNFe.procNFe.digVal); QRCode.Data := sURL; // TQRCodeEncoding = (qrAuto, qrNumeric, qrAlphanumeric, qrISO88591, qrUTF8NoBOM, qrUTF8BOM); // 0=Auto, 1=Numeric, 2=Alphanumeric, 3=ISO-8859-1, 4=UTF-8 without BOM, 5=UTF-8 with BOM QRCode.Encoding := qrAuto; //TQRCodeEncoding(0); QRCode.QuietZone := 2; QRCodeBitmap.Width := QRCode.Rows; QRCodeBitmap.Height := QRCode.Columns; for Row:=0 to QRCode.Rows-1 do begin for Column:=0 to QRCode.Columns-1 do begin if (QRCode.IsBlack[Row, Column]) then QRCodeBitmap.Canvas.Pixels[Column, Row] := clBlack else QRCodeBitmap.Canvas.Pixels[Column, Row] := clWhite; end; end; finally QRCode.Free; end; qriQRCode.Canvas.Brush.Color := clWhite; qriQRCode.Canvas.FillRect(Rect(0, 0, qriQRCode.Width, qriQRCode.Height)); if ((QRCodeBitmap.Width > 0) and (QRCodeBitmap.Height > 0)) then begin if (qriQRCode.Width < qriQRCode.Height) then Scale := qriQRCode.Width / QRCodeBitmap.Width else Scale := qriQRCode.Height / QRCodeBitmap.Height; qriQRCode.Canvas.StretchDraw(Rect(0, 0, Trunc(Scale * QRCodeBitmap.Width), Trunc(Scale * QRCodeBitmap.Height)), QRCodeBitmap); end; finally QRCodeBitmap.Free; end; end;

Olá leufmt, Cara... pelo que estou percebendo, você está com dois problemas distintos relacionados ao QR-CODE: 1) Não está conseguindo autorizar o XML, não está gerando o QR-CODE correto. Se utilizar o trunk2 com ACBrNFe, basta setar a propriedade ACBrNFe.Configuracoes.Geral.IncluirQRCodeXMLNFCe para True, mas para funcionar vale a ressalva do André, setar corretamente o IdCSC e CSC no ambiente correto. Outra coisa é garantir o seu trunk2 atualizado para gerar com as URLs corretas. 2) Você utiliza DANFE próprio e não está conseguindo gerar a imagem do QR-CODE correto. Também tenho DANFE próprio, que copiei do ACBr a muito tempo atrás, que foi o DANFE com QuickReport, e de lá copiei a geração da imagem do QR-CODE... nem sei dizer se tem uma forma mais eficiente de gerar essa informação, mas ainda tenho essa codificação e está funcionando, ou seja, ao ler de um smartfone vai para o site de boa. Se for isso que está querendo me avisa que posto aqui. Qualquer coisa avisa.

Olá ti_smig, A sistema MENSAGEIRA, que é seu autorizador, tem todas as informações que você precisa assim que autorizar nas propriedades de ACBrNFe.NotasFiscais.Items[0].NFe.procNFe. Até aí tudo bem, então à partir daí você escolhe a melhor forma para responder para o seu PDV. Tenho algo muito parecido com a sua arquitetura, mas não preciso fazer nada na unha, utilizo o componente ACBrNFe para ler as propriedades com o uso de loadfromfile, por exemplo, caso você prefira, bastaria o sistema MENSAGEIRA responder ao seu PDV que a nota foi autorizada com o XML completo, então no PDV você utiliza o ACBrNFe.NotasFiscais.LoadFromFile(...); e pronto, você teria acesso a todas as propriedades da autorização em ACBrNFe.NotasFiscais.Items[0].NFe.procNFe. No meu caso ainda, utilizo o componente ACBrNFe no PDV só para preencher todas as propriedades e então gero um XML sem assinatura, apenas para servir de layout, então no que seria minha MENSAGEIRA, dou loadfromfile, e efetuo o envio da nota (onde será assinada e enviada), então ao ser autorizada, respondo ao PDV com ok, e então o PDV dá um loadfromfile para pegar os dados da autorização. Assim não tenho preocupação com layout e trabalhando sempre com o componente. Então é isso... espero não ter bagunçado a sua cabeça... a intenção era ajudar.

Pelo que entendi você vai responder em um layout próprio e gostaria apenas de saber como ler as informações da autorização? Se for isso, após a autorização basta ler as propriedades de: ACBrNFe.NotasFiscais.Items[0].NFe.procNFe Estarão todas preenchidas. Não sei se foi exatamente isso que queria saber... espero ter ajudado.

Abra o seu XML e notará que está com preenchimento inválido: <protNFe versao="3.10"> <infProt> <tpAmb>1</tpAmb> <verAplic>QAD</verAplic> <chNFe/> <dhRecbto>2016-09-27T19:03:44-03:00</dhRecbto> <nProt>135160601013566</nProt> <digVal>wpVJjhVZFgN5jg3CyFZx4LKKUi4=</digVal> <cStat>100</cStat> <xMotivo>Autorizado o uso da NF-e</xMotivo> </infProt> </protNFe> A chave não está preenchida no protocolo de autorização.

Olha só Rafael, veja se a sua situação não se enquadra em uma dessas situações:

Gabriel, dá uma verificada em suas configurações imediatamente antes de enviar a NFC-e (ACBrNFe1.Enviar), talvez você esteja perdendo as configurações na sua codificação e não tenha percebido. Antes do enviar verifica se as configurações ainda estão corretas,como: ACBrNFe1.Configuracoes.Geral.ModeloDF ACBrNFe1.Configuracoes.Geral.VersaoDF ACBrNFe1.Configuracoes.WebServices.Ambiente ACBrNFe1.Configuracoes.Geral.IdCSC ACBrNFe1.Configuracoes.Geral.CSC Não me lembro de ninguém ter esse tipo de problema, então fica aí a dica de verificar os seus fontes. Gabriel, a dica do JNPace é pertinente, também utilizo o ambiente de homologação de GO, no site eles mostram o identificador do CSC, por exemplo, como 1, mas na prática, você tem que preencher o componente com zeros à esquerda, ficando com seis caracteres, ficando 000001. Além disso, acredito que está invertendo o preenchimento dos campos, deveria ser algo do tipo: ACBrNFe1.Configuracoes.Geral.IdCSC := '000001'; ACBrNFe1.Configuracoes.Geral.CSC := '9e0c9eec1cf06209'; Espero ter ajudado.

@Anderson Dani Estava quase fazendo isso também... O duro é que tem tanta configuração, windows danificado, vírus.... que as vezes uma boa e velha formatação acaba sendo ainda uma boa solução. Mas que bom que resolveu o seu problema com a formatação.

Estava com o mesmo problema em MT, em WinXP, e pra mim a solução foi esta:

Sei que não está diretamente ligado ao tópico, já que se referia ao ACBrMonitorPlus, mas no meu caso acabei descobrindo o problema com o uso do componente ACBrNFe. Era uma propriedade: ACBrNfe.Configuracoes.GeralSSLLib Por default no meu componente estava "libCapicomDelphiSoap" onde só funcionava adequadamente no Win7, então coloquei "libCapicom", então agora voltou a funcionar normalmente em WinXP e Win7. Se alguém passar por isso com o componente, vale a tentativa... para mim deu tudo certo.

@Anderson Dani Conseguiu resolver esse problema? Estou com a mesma mensagem no WinXP, só que não utilizo o ACBr Monitor, utilizo o componente ACBrNFe. Já coloquei todas as dlls no System32, registrei Capicom manualmente, alterar a propriedades do IE, certificado não está expirado, e nada... O mesmo executável do meu sistema funciona normalmente em uma máquina Win7... não sei o que fazer para funcionar no XP. Alguma coisa adicional que possa testar pessoal?

Alguém pessoal? O duro é que agora que vou ficar com o cabelo mais branco ainda, pois consegui o certificado do cliente para testar o ambiente de MT, e para a minha surpresa no ambiente de Homologação em MT está funcionando normalmente a Consulta, quando vou testar a Consulta no ambiente de Produção não funciona de jeito nenhum... não sei o que fazer... dá a mensagem: The server returned an invalid or unrecognized response - URL:https://nfe.sefaz.mt.gov.br/nfews/v2/services/NfeConsulta2?wsdl - SOAPAction:http://www.portalfiscal.inf.br/nfe/wsdl/NfeConsulta Alguma sugestão? Ninguém está com esse problema em Produção em MT?

Pessoal, quem tem clientes em MT está conseguido consultar NF-e? Aparentemente nenhum cliente meu não está conseguindo a um bom tempo, e o erro retornado é o seguinte: The connection with the server was reset - URL:https://nfe.sefaz.mt.gov.br/nfews/v2/services/NfeConsulta2?wsdl - SOAPAction:http://www.portalfiscal.inf.br/nfe/wsdl/NfeConsulta 28-06-2016 14:30:21 - Comando "cmdCancelarNFe" - Resp: The connection with the server was reset - URL:https://nfe.sefaz.mt.gov.br/nfews/v2/services/NfeConsulta2?wsdl - SOAPAction:http://www.portalfiscal.inf.br/nfe/wsdl/NfeConsulta Tenho clientes em outros estados e está tudo normal. Estou perdido e nem tenho como testar o ambiente de lá, pois só tenho certificado do GO, onde tudo está funcionando perfeitamente. Alguma dica do que eu possa verificar?

@Renato Rodrigues Ontem à tarde não ocorreu a rejeição 397, mas ainda o ambiente tinha algumas instabilidades, pois autorizava e não retornava o protocolo. Mas hoje já eviei duas NFC-e em homologação e funcionou de primeira, autorizou normalmente sem problema algum. Tudo indica que o ambiente de homologação está estável por agora.

O padrão que o ACBrNFe gera, ao utilizar ACBrNFe.Configuracoes.Geral.IncluirQRCodeXMLNFCe := True, é a segunda opção que mostrei, conforme as especificações em notas técnicas e que já está funcionando em todo o Brasil que já tem disponível NFC-e. O próprio Renato me informou que iria rever as regras do QR-CODE para respeitar exatamente a Nota Técnica 2015.002 v1.40, na página 10, onde cita o CDATA. Olha a imagem:

@RobertoRP Analisando o seu XML, na verdade nem sei como autorizou antes, talvez até porque as regras em GO não estava validando 100%, mas percebi que a forma que está gerando a informação do QR-CODE não está correta. Você está gerando assim: <infNFeSupl> <qrCode>https://homolog.sefaz.go.gov.br/nfeweb/jsp/ConsultaDANFENFCe.jsf?chNFe=52160621025760000123650010000002011756345955&amp;nVersao=100&amp;tpAmb=2&amp;dhEmi=323031362d30362d32305432333a31393a32372d30333a3030&amp;vNF=1.50&amp;vICMS=0.00&amp;digVal=5768446b3379674e5538395264624e4269317161513055353134673d&amp;cIdToken=000001&amp;cHashQRCode=9e1874b24ef6b2daef6714f484fd173fc20e94bf</qrCode> </infNFeSupl> Sendo que o que deve ser gerado é algo do tipo: <infNFeSupl><qrCode><![CDATA[http://homolog.sefaz.go.gov.br/nfeweb/jsp/ConsultaDANFENFCe.jsf?chNFe=52160604429915000178650010000004651000036832&nVersao=100&tpAmb=2&cDest=93040083104&dhEmi=323031362D30362D32335431303A32373A33392D30333A3030&vNF=42.24&vICMS=0.00&digVal=74395A737A4A7979616F685537476549676F476B6A4363575833733D&cIdToken=000001&cHashQRCode=3E5A79517CF241E82E28C870F750341F16FDD145]]></qrCode></infNFeSupl> Note as diferenças como o CDATA, o "&" e tudo mais, destaquei em vermelho. Você está utilizando o componente atualizado do ACBrNFe, ou é codificação própria?

@Juliomar Marchetti Vi que atualizou no svn os links de NFC-e de GO, mas ontem mesmo recebi os links diretamente da SEFAZ/GO e em relação à consulta do QR-CODE, não existe o "s" nas URLs. Apesar do pessoal estar conseguindo autorizar das duas formas, seria interessante deixar no svn o dito "correto", afinal foi a própria SEFAZ/GO que me enviou. Então ficaria: [NFCe_GO_P] ... URL-QRCode=http://nfe.sefaz.go.gov.br/nfeweb/jsp/ConsultaDANFENFCe.jsf URL-ConsultaNFCe=http://nfe.sefaz.go.gov.br/nfeweb/jsp/ConsultaDANFENFCe.jsf [NFCe_GO_H] ... URL-QRCode=http://homolog.sefaz.go.gov.br/nfeweb/jsp/ConsultaDANFENFCe.jsf URL-ConsultaNFCe=http://homolog.sefaz.go.gov.br/nfeweb/jsp/ConsultaDANFENFCe.jsf Vi que até em outro tópico do ACBrMonitor PLUS: ...você informa que publicou os links, só que lá eles mesmos já tinham passado sem o "s" na URLs de consulta. Se puder atualizar para nós, e assim todos usarem as mesmas URLs, agradeço muito. Pessoal, estou conseguindo autorizar NFC-e em GO em Homologação hoje. O único problema é que o ambiente está se mostrando instável, hora dá "Rejeição: Parâmetro do QR-Code divergente da Nota Fiscal", hora retorna a resposta vazia, onde o ACBrNFe naturalmente não consegue processar a resposta e hora acaba autorizando, tudo isso emitindo a mesma NFC-e sem alterar em nada o seu conteúdo. O @Renato Rodrigues se mostrou muito solícito para ajudar a estabilizar o ambiente em GO, inclusive enviei as chaves da NFC-e que autorizei hoje para que ele possa analisar os logs. Já tem cliente interessado em implantar a NFC-e em Produção aqui em GO, mas estou muito receoso com as instabilidade apresentadas em Homologação. Espero que possam resolver logo.

@Renato Rodrigues Estou com problemas como os companheiros acima. <cStat>397</cStat> <xMotivo>Rejeição: Parâmetro do QR-Code divergente da Nota Fiscal</xMotivo> Solicitei, hoje pela manhã, ao atendimento na SEFAZ/GO as URLs dos servidores para comparar se as do ACBr estavam ok, e a única diferença que vi foi a questão do "s" na URL de consulta do QR-CODE. Em fim, testei das duas formas (com e sem "s") e só obtenho a rejeição, sendo que tenho clientes emitindo no AM e em MT, sem nenhum problema. Em anexo segue o XML, com o lote e a nfc-e que está recebendo a rejeição em homologação: 301-env-lot.xml

Ok. Segue o arquivo com a alteração. Incluídas as url do Amapa (AP), produção e homologação, fonte: https://www.sefaz.ap.gov.br/index.php/component/content/article/201-nfc-e/8190-desenvolvedores-de-softwares Arquivo: ACBrNFeServicos.ini

Só para informação, funcionou no ambiente de PRODUÇÃO em meu cliente.