Fabrício G. Araújo

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?

A do RS a URL tem o https, então na minha interpretação passaria normalmente pelos schemas (... ((HTTPS?|https?)://.*\? ...) Estou estudando os fontes do trunk2 e modificando apenas o necessário no trunk1, sei que não é o ideal e que o trunk1 não recebe mais atualizações, por isso estou implementando, mas como disse não dá para migrar agora, mas com certeza quando tiver tempo migrarei tudo para o trunk2. Os schemas que estou utilizando são os mais atuais, do trunk2, tanto é que validou o qrCode. Tem mais alguém com URL "http" que conseguiu autorizar a NFC-e em homologação? Principalmente no AM? O que poderia estar de errado no meu XML?

mbbortolini, para qual UF você fez o teste em homologação? No meu caso estou apenas tapando o buraco em relação ao QR-Code no meu trunk1, existem algumas codificações próprias que me impediriam agora de migrar para o trunk2, estou na correria com outros projetos, então quando tiver um tempinho vou migrar tudo para o trunk2. Olha o primeiro XML que gerei para teste: 13151004429915000178650010000004611000008741-nfe.xml Então obtive esse restrição: '<![CDATA[http://homnfce.sefaz.am.gov.br/nfceweb/consultarNFCe.jsp?chNFe=13151004429915000178650010000004611000008741&nVersao...' violates pattern constraint of '((HTTPS?|https?)://.*\?chNFe=[0-9]{44}&nVersao=[0-9]{3}&tpAmb=[1-2](&cDest=([A-Za-z0-9.:+-/)(]{0}|[A-Za-z0-9.:+-/)(]{5,20})?...'. The element '{http://www.portalfiscal.inf.br/nfe}qrCode' with value '<![CDATA[http://homnfce.sefaz.am.gov.br/nfceweb/consultarNFCe.jsp?chNFe=13151004429915000178650010000004611000008741&nVersao...' failed to parse. 13151004429915000178650010000004611000008741-nfe.xml

Boa tarde pessoal, Olha só... me ajuda a entender uma coisa... acabei de atualizar os schemas, com o que tem de mais novo, e a validação do qrCode está assim: <xs:simpleType> <xs:restriction base="xs:string"> <xs:whiteSpace value="preserve"/> <xs:minLength value="100"/> <xs:maxLength value="600"/> <xs:pattern value="((HTTPS?|https?)://.*\?chNFe=[0-9]{44}&amp;nVersao=[0-9]{3}&amp;tpAmb=[1-2](&amp;cDest=([A-Za-z0-9.:+-/)(]{0}|[A-Za-z0-9.:+-/)(]{5,20})?)?&amp;dhEmi=[A-Fa-f0-9]{50}&amp;vNF=(0|0\.[0-9]{2}|[1-9]{1}[0-9]{0,12}(\.[0-9]{2})?)&amp;vICMS=(0|0\.[0-9]{2}|[1-9]{1}[0-9]{0,12}(\.[0-9]{2})?)&amp;digVal=[A-Fa-f0-9]{56}&amp;cIdToken=[0-9]{6}&amp;cHashQRCode=[A-Fa-f0-9]{40})"/> </xs:restriction> </xs:simpleType> Os endereços de homologação do AM estão assim: URL-QRCode=http://homnfce.sefaz.am.gov.br/nfceweb/consultarNFCe.jsp URL-ConsultaNFCe=http://homnfce.sefaz.am.gov.br/nfceweb/formConsulta.do Pelo meu entendimento a validação dos schemas não aceitará a URL diferente de HTTPS ou https, então como passaria na validação as URLs de homologação do AM? Minha interpretação está correta ou estou falando besteira?

Bom dia Ítalo, Estava sem entender ao ler todo o início do post sobre todos falando da obrigatoriedade do QR-Code no XML, pois realmente confirmei que a SEFAZ do AM e de GO, não validam essa informação, pois autorizei normalmente em homologação (hoje 15/10/2015, sendo que o prazo era 01/10/2015) sem informar as tags infNFeSupl e qrCode. Terei problemas para implementar manualmente as alterações, pois ainda possuo o trunk com programações próprias e no momento não tenho tempo para migrar para o trunk2. Para ter uma ideia da bagunça dessas SEFAZ, a do AM nem sequer valida o primeiro item em homologação com a descrição "NOTA FISCAL EMITIDA EM AMBIENTE DE HOMOLOGACAO - SEM VALOR FISCAL", já a de GO efetua essa validação. Espero não ter problemas dia 03/11/2015... Atenciosamente, Fabrício Gomes Araújo

Régys, até tinha visto essa informação no site de MG, mas na prática interpretei apenas que eles transcreveram a informação que está na Nota Técnica 2013.005, tanto é que no texto diz o seguinte: "Sendo recepcionado as duas versões até esta data e a desativação da versão "2.00" da NF-e em 01/12/2014.". No meu entendimento as duas versões funcionarão até esta data. A própria NT fala que em produção estaria disponível em 10/03/2014, ou seja, todas as federações deveriam ter disponibilizado até esta data. Infelizmente o governo não respeita nem seus próprios prazos definidos. Como o Astrogildo82 mesmo disse, vai acabar entrando em produção a 3.10 em MG na véspera, ou contar com um prorrogação. Agora vou ter que modificar o meu sistema para emitir das duas versões 2.0 e 3.10, faz parte. Obrigado pelas informações. Fabrício Gomes Araújo

Vixe... aí me enrolei... o sistema foi todo ajustado para trabalhar somente com a 3.10. Obrigado pela informação Régys. Régys ou mais alguém saberia me dizer quando entrará em produção o ambiente de NF-e 3.10 de MG? Fabrício Gomes Araújo

Amigos, Pesquisei no fórum sobre o assunto, mas só achei posts antigos, inclusive tentei as mesmas soluções propostas e não obtive sucesso. Gostaria de saber se alguém possui clientes emitindo NF-e 3.10 em Produção em MG, pois está ocorrendo o erro: "Rejeicao: Cabecalho - Versao do arquivo XML nao suportada", em um cliente de MG, mas tenho clientes em GO e MT que estão utilizando a mesma versão do meu sistema e funciona tudo ok. Já gerei um novo sistema de teste baixando a versão mais atual do ACBr (em 15/07/2014 revisão 7152), também atualizei os arquivos de esquemas e nada de funcionar. Em anexo estou enviando os arquivos temporários do ACBrNFe do envio e recebimento do lote com a restrição e o Log também. Se puderem me ajudar, agradeço desde já. Fabrício Gomes Araújo 206-env-lot.xml 206-rec.xml log.txt