Fabrício G. Araújo

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

Com as urls que obtive para o QR-CODE no Amapá (AP), ficaria assim: [NFCe_AP_P] Usar=NFCe_SVRS_P URL-QRCode=https://www.sefaz.ap.gov.br/nfce/nfcep.php URL-ConsultaNFCe=https://www.sefaz.ap.gov.br/sate/seg/SEGf_AcessarFuncao.jsp?cdFuncao=FIS_1261 [NFCe_AP_H] Usar=NFCe_SVRS_H URL-QRCode=https://www.sefaz.ap.gov.br/nfcehml/nfce.php URL-ConsultaNFCe=https://www.sefaz.ap.gov.br/sate1/seg/SEGf_AcessarFuncao.jsp?cdFuncao=FIS_1261 Correto?

Pessoal, estou com o mesmo problema no Amapá (AP), entrei no site da Sefaz de lá e achei a url: https://www.sefaz.ap.gov.br/index.php/component/content/article/201-nfc-e/8190-desenvolvedores-de-softwares " Atendendo a NT 002.2015, o link que deve ser utilizado para geração do QR-CODE da NFC-e emitida em Produção é https://www.sefaz.ap.gov.br/nfce/nfcep.php , e a consulta da NFC-e emitida em produção segue sendo realizada no link: https://www.sefaz.ap.gov.br/sate/seg/SEGf_AcessarFuncao.jsp?cdFuncao=FIS_1261 " Por favor, peço ao moderadores para incluir no arquivo ACBrNFeServicos.ini. Agora vou tentar colocar manualmente no arquivo e tentar gerar o arquivo .res e recompilar minha aplicação. Nunca fiz isso, espero que não tenha problemas. Atenciosamente, Fabrício Gomes Araújo

Antes mesmo no trunk eu utilizava da forma que falei, mas não sei dizer porque funcionava com você, mas tendo o ambiente funcionando é o que tá valendo, assim dá para testar normalmente.

Foi o que imaginei mesmo Italo, obrigado pela explicação. Infelizmente então em caso de um problema no momento da inutilização do número não tenho como recuperar os dados dessa inutilização. Então para manter o histórico dos números inutilizados com sucesso dentro do meu sistema, o que implementei agora foi que se o usuário tentar inutilizar novamente, pois não obteve resposta por um eventual erro, então ao inutilizar será retornado o status 206 (Rejeição: NF-e já está inutilizada na Base de dados da SEFAZ), então guardo no meu sistema que aquela numeração foi inutilizada.

Imagino que não tenha essa opção mesmo... Até efetuei um teste como me indicou utilizando a consulta pela chave do demo, então testei informar a chave da Inutilização, como: 13160442991500017865001000000483000000483, então dá chave inválida, pois imagino que está esperando por uma chave de 44 dígitos de NF-e/NFC-e, e mesmo que tente forçar a barra inventando uma chave de 44 dígitos, não iria achar, pois a nota nunca existiu foi só inutilizado o número. Obrigado mais uma vez Juliomar.

Valeu por responder Juliomar. Só não entendi exatamente qual xml carregar, você se refere ao que foi enviado inicialmente com o pedido de inutilização? O que seria essa consulta de protocolo? Atualmente a única consulta que tenho é onde carrego a NF-e/NFC-e com LoadFromFile e consulto.

Tenho uma dúvida relacionada a Inutilização, pois no caso de Autorização de NF-e, caso dê um erro neste momento, posso posteriormente efetuar uma Consulta e então receber os dados do protocolo e status 100, até aí tudo ok, mas se tiver problemas no momento da Inutilização, existe alguma forma de recuperar o protocolo, data/hora do processamento, motivo e status 102?

Sou de GO (certificado de GO) e tenho usado NFC-e no AM em Homologação sem problemas, só que tenho que configurar no endereço do WebService, do Emitente e do Destinatário (se for preenchido) o UF AM.

Ontem mesmo desisti de testar a consulta da NF-e cancelada em GO, então iniciei os testes com consulta de NFC-e do AM e aí sim respondeu como me informou o Italo, gerando o arquivo <chave>-NFeDFe.xml. Agora é torcer para que essas instabilidades não ocorram em produção. Uma coisa que percebi é que quando efetua um Cancelamento e tudo funciona, é gerado o arquivo *-procEventoNFe.xml, mas ao Consultar uma nota já cancelada não gera esse arquivo. Então para poder armazenar esse arquivo, estou gerando ele na mão. No meu caso funciona bem, pois o único evento que poderá estar associado é o de Cancelamento, abaixo vou mostrar como faço para gerar o arquivo *-procEventoNFe.xml idêntico ao que obtém quando efetua o Cancelamento, só que através de uma Consulta: var strAux: String; Leitor: TLeitor; strList: TStringList; NomeArqEvento: String; begin ACBrNFe.NotasFiscais.Clear; ACBrNFe.NotasFiscais.LoadFromFile(PastaEnv + FNomeArquivoXML); if ACBrNFe.Consultar() then begin if (ACBrNFe.WebServices.Consulta.procEventoNFe.Count > 0) and (ACBrNFe.WebServices.Consulta.procEventoNFe.Items[0].RetEventoNFe.cStat in [135, 155]) then begin NomeArqEvento := Copy(ACBrNFe.WebServices.Consulta.procEventoNFe.Items[0].RetEventoNFe.InfEvento.id, 3, 52) + '-procEventoNFe.xml'; Leitor := nil; strList := nil; try // Vamos remover as tags desnecessárias para gerar o arquivo do Evento de Cancelamento Homologado completo // como se tive acabado de efeturar o cancelamente e dado tudo certo Leitor := TLeitor.Create; strList := TStringList.Create; Leitor.Arquivo := ACBrNFe.WebServices.Consulta.RetWS; strAux := Leitor.rExtrai(1, 'procEventoNFe', 'procEventoNFe'); strAux := StringReplace(strAux, '<procEventoNFe versao="1.00">', '<procEventoNFe versao="1.00" xmlns="http://www.portalfiscal.inf.br/nfe">', [rfReplaceAll]); strAux := '<?xml version="1.0" encoding="UTF-8"?>' + strAux; strList.Text := strAux; strList.SaveToFile(PastaCanceladas + NomeArqEvento); finally Leitor.Free; strList.Free; end; end; end; end; Dessa forma tem resolvido para mim quando dá algum problema no momento do Cancelamento e o meu sistema não armazena os dados e então quando o usuário tenta cancelar novamente eu disparo essa rotina acima. Obs: Para utilizar a classe TLeitor, tem que adicionar no uses: pcnLeitor Espero que possa ser útil para alguém. Abraços, Fabrício Gomes Araújo

Estou com o mesmo problema. Alguém está conseguindo emitir a NFC-e com QR-Code em homologação em Goiás?

Já utilizada os dois Italo, copiei o errado: ACBrNFe.Configuracoes.Arquivos.Salvar := True; ACBrNFe.Configuracoes.Geral.Salvar := True; O fato de não gerar o arquivo <chave>-NFeDFe.xml pode ser uma instabilidade em GO (homologação)?

Bom dia Italo, Obrigado por tentar ajudar. Sobre as considerações que fez, utilizo exatamente como descreveu e em nenhum momento gera o arquivo <chave>-NFeDFe.xml, sendo que para consultar faço assim: ACBrNFe.NotasFiscais.Clear; ACBrNFe.NotasFiscais.LoadFromFile(PastaEnv + FNomeArquivoXML); if ACBrNFe.Consultar() then E o componente está configurado corretamente, como: ACBrNFe.Configuracoes.Geral.Salvar := True; A NF-e que citei acima já está cancelada, apesar que no site de GO ainda não mostra que está, o que é estranho é que nem no ambiente de homologação nacional estão aparecendo as minhas notas. Hoje fiz mais um teste de consulta e me retorna que está cancelada, mas sem o evento. O arquivo de retorno está assim: 52160104429915000178550000000004661000079213-sit.xml O duro é saber como proceder em meu sistema, pois ontem após o cancelamento em uma Consulta não retornava que o Cancelamento estava homologado, e hoje já retorna mas sem o evento associado. Isso pode ser uma instabilidade em GO homologação? Acontece o mesmo com você?

Pessoal, pesquisei e já ficou claro que a NF-e não terá o XML alterado caso a mesma seja Cancelada, mantendo o seu cStat 100, sendo que a propriedade ACBrNFe.Configuracoes.Geral.AtualizarXMLCancelado não possui mais efeito algum, até aí tudo bem, o que gostaria de saber o que posso fazer para tratar situações de erros em que não consiga receber a resposta do evento de Cancelamento para situações de queda de energia, ou da internet no momento do Cancelamento? Antes para toda tentativa de Cancelamento eu enviada um Consulta para saber se já estava cancelado ou não, agora não faz efeito pois o cStat não muda. Outra coisa que achei estranho é que em nenhum momento me retornou o *-NFeDFe.xml como o colega sistemp informou acima. Para essa situação o que vocês sugerem? Como identificar que já foi cancelado? Em anexo estou enviando o XML em homologação como autorizado, já efetuei o cancelamento do mesmo. 52160104429915000178550000000004661000079213-nfe.xml

Estou tentando instalar o trunk2 no Delphi6 e até consegui (depois de muito trabalho e colocando os componentes básicos), concluindo a instalação pelo ACBrInstall_Trunk2.exe. Quando estava comemorando achando que tinha dado tudo certo... ao abrir o Delphi deu várias mensagens, todas informando a mesma coisa como: O que posso fazer para tirar essa incompatibilidade? Vamos lá pessoal, dá uma ajudinha aí... apesar de saber que não é mais dado suporte ao Delphi6.

Pessoal, tenho o mesmo problema do ramalho, mas para tentar minimizar os meus problemas no Delphi6 apenas utilizo as classes dos objetos para trabalhar em alto nível e utilizar as propriedades para ler e setar valores, como load e save, e então tenho o componente em Delphi7 onde aí sim lê o certificado, efetua a autorização e tudo mais. Como se eu tivesse um micro-Monitor onde faz o grosso das coisas. Como o sistema é mínimo em Delphi7 seria tranquilo utilizar uma nova plataforma. Mesmo sabendo da incompatibilidade do Delphi6, tem algo que possa fazer na instalação para apenas utilizar as classes como falei, ou seja, não preciso de certificado, autorização, webservices... nada disso. Se puderem ajudar agradeço muito.

Sucesso. Autorizada a NFC-e no ambiente de homologação do AM. Conforme XML: 13151004429915000178650010000004611000008741-nfe.xml Nas minhas adaptações, ficou faltando alterar o método "wCampo" de "pcnGerador", que foi modificado acrescentando um novo parâmetro "ParseTextoXML", que mantém os caracteres especiais, então funcionou. Obrigado pela ajuda mbbortolini. 13151004429915000178650010000004611000008741-nfe.xml

Realmente mbbortolini, como estava abrindo o XML no navegador, então ele converte esses caracteres e visualizava como estivesse tudo ok, vou dar uma ajustada aqui e posto o resultado se deu certo. Obrigado.

Régys, quando falo que não dá para migrar agora, não é por conta do componente, e sim pela correria aqui na empresa. Por mais que os administradores do grupo recomendem manter o componente sempre atualizado, não faço isso, pois mantenho uma versão estável e então só mecho ou atualizo em situações emergenciais. Da última vez que atualizei, foi para integrar com a nova versão 3.10 (um ano atrás), onde disponibilizei no meu sistema a NFC-e, antes tinha somente NF-e, e foi um transtorno danado para mim, demorei muito tempo para estabilizar o sistema, pois muita coisa tinha mudado, até questões de pegar os dados da nota e tudo mais, acredito que agora aconteceria o mesmo e como estou envolvido com outros projetos, neste momento o mais viável para mim seria apenas tapar o buraco emergencial. Até porque nem sequer estou preocupado com a NT2015.003, pois os meus clientes utilizam o básico do básico, então apenas vou ajustar o que irá impactar diretamente, que será o caso do qrCode. Além disso ainda tem as codificações próprias que possuo no ACBrNFe, e para ser sincero ainda não sei o impacto para outros componentes no trunk2 para ACBrECF, ACBrETQ, ACBrBarCode que são componentes que também utilizo. Desculpe a dissertação acima. Mas você chegou a ver o meu XML, o que será que estou fazendo que errado que não percebi?