Fabrício G. Araújo

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

Valeu d+ André. Imagino que como em GO não existe NFC-e, então eles não devem ter modificado as regras nos seus servidores. Infelizmente não terei como testar, então será colocar nos clientes em produção e ver no que vai dá. Obrigado. Fabrício Gomes Araújo

O meu teste é meio que uma forçada de barra, já que tenho certificado de GO para emitir NF-e em homologação e para emitir NFC-e em homologação tenho que usar o ambiente do AM. Estava pelo menos esperando uma rejeição de UF divergente ou algo do tipo, mas restringir o modelo achei estranho. Segue em anexo a NF-e. 52140504429915000178550000000001261000002368-nfe.xml

Amigos, Vi que na nova nota técnica NT2013.005_v1.03 o campo de referência da nota irá aceitar referenciar uma NFC-e (modelo 65), conforme está descrito: Campo: refNFe Descrição: Chave de acesso da NF-e referenciada Observação: Referencia uma NF-e (modelo 55) emitida anteriormente, vinculada a NF-e atual, ou uma NFC-e (modelo 65), Então estou utilizando a NF-e na versão 3.10 e tentei referenciar uma NFC-e, só que acabou retornando restrição que o modelo da nota referenciada é diferente de 55. Alguém conseguiu fazer esse tipo de operação? Será que essa restrição é por Sefaz? Obrigado, Fabrício Gomes Araújo

Astrogildo82, Me deparei com a mesma situação sua, só que no meu caso foi com o evento de Cancelamento, então o que fiz foi pegar o arquivo de resposta da Consulta (o arquivo que está em disco nome: "chave-sit.xml") e removi as tags que não interessavam e deixei o arquivo exatamente igual ao Evento de Cancelamento quando é efetivado diretamente. Um exemplo do que fiz seria algo do tipo: var Leitor: TLeitor; str: String; begin Leitor := TLeitor.Create; Leitor.CarregarArquivo('52130704429915000178550000000000821000000305-sit.xml'); str := Leitor.rExtrai(1, 'procEventoNFe', 'retConsSitNFe'); Memo1.Text := '<?xml version="1.0" encoding="UTF-8" ?>' + str; Leitor.Free; end; Para usar a classe TLeitor, basta dar uses na pcnLeitor. No exemplo acima deixei no Memo1 apenas o conteúdo do Evento de Cancelamento homologado, bastaria salvar em disco ou armazenar no banco. Não sei se essa é a maneira mais correta de se fazer, mas é a que utilizo atualmente. Se algum colega fizer de forma menos acochambrada gostaria de saber. Fabrício Gomes Araújo

Conforme sugestão do Régys, e antes tarde do que nunca, segue um PDF com o conteúdo deste post com todos os campos de ICMS e seus respectivos diagramas: DiagramaCST_CSOSN.pdf PS - Obrigado mais uma vez Daniel, por ajustar o acesso a este post. Abraços, Fabrício Gomes Araújo

Bom saber IrLucas, acabei de atualizar o ACBrNfe, agora estou dependendo do cliente para poder testar. Valeu, Fabrício Gomes Araújo

Valeu Italo, muito obrigado. Fabrício Gomes Araújo

Utilizo o Delphi 6 com os componentes do ACBr para trabalhar com NF-e, já fazia um tempão que não atualizava o componente, então tive que fazer uma alteração na ACBrNFeDANFeQRRetrato.pas para que meu sistema compilasse. O QR que possuo é o padrão, ou seja, não gera PDF, então onde estava na Linha 101, assim: DBClient, ACBrNFeDANFEClass, ACBrNFeDANFeQRClass, QRPDFFilt; Alterei para: DBClient, ACBrNFeDANFEClass, ACBrNFeDANFeQRClass{, QRPDFFilt}; Esse ajuste que fiz procede? Como sugestão isso poderia ser ajustado nos fontes originais baseado em diretiva (QReport_PDF) para que funcione para todos? Abraços, Fabrício Gomes Araújo

Sim markapollo, os Schemas acabei de baixar e trocar os do cliente. Só não recompilei o sistema com o componente ACBrNfe atualizado... vou começar a preparar a atualização do componente para ver se funciona... Fabrício Gomes Araújo

Estou com o mesmo problema para Cancelamento em MG ("Cabecalho - Versao do arquivo XML nao suportada"), em GO funciona perfeitamente. Atualizei os Schemas no cliente de MG e deu a mesma restrição... já pesquisei na lista e já falaram que se atualizasse os Schemas poderia dar certo... é fato que não utilizo o ACBrNFe já faz algum tempo. A nota foi emitida (Autorizada) ontem e está tentando efetuar o Cancelamento hoje. Se atualizar o componente irá funcionar? Porque em GO funciona? Fabrício Gomes Araújo

André, O programa que utilizei chama EditX, utilizei a versão 2010 que era free. Pesquisei na net e achei o link atual: http://www.editix.com/download.html Dei uma olhada rápida no site e não achei fácil se ainda existe uma versão free. Abraços, Fabrício Gomes Araújo

Está aí minha pequena contribuição... e obrigado pela ajuda Daniel. Abraços, Fabrício Gomes Araújo

André, caso não consiga recuperar as imagens, por favor, me avise, pois acredito que ainda tenho aquelas imagens em meu computador, então acredito que poderia editar o post inserindo elas novamente. É claro que faria isso somente se o pessoal do fórum ainda achar aquele post pertinente. Fabrício Gomes Araújo

Muito legal a nova interface. Parabéns aos responsáveis que mantém esse fórum. Só uma coisa que achei estranho, é que postagens mais antigas ficaram com as imagens todas distorcidas. Vocês perceberam isso também? Ou só está acontecendo comigo. Por exemplo, vejam esse tópico que eu mesmo criei a algum tempo: Fabrício Gomes Araújo

Amigos, Venho ressuscitar este post, que eu mesmo criei, para alertar o pessoal que possa vir a homologar o sistema em Goiânia. Acabei de homologar o meu sistema na ER 01.11 (finalizado em 18/06/2012). Então esse ano tinha resolvido fazer tudo certinho como manda o roteiro, como utilizar a "mensagem complementar" para o MD5 e a "mensagem suplementar" (mesmo da promocional de ECF de convênios mais antigos) para DAV, PV, MINAS LEGAL e tudo mais. Pois é, o pessoal daqui simplesmente não entende a diferença de mensagem complementar de suplementar, e ainda pelo fato do fabricante alterar a mensagem complementar, por exemplo, a Bematech adiciona "Aplicativo:" e a Daruma aciona 3 espaços em branco, simplesmente não aceitaram a forma "correta" que eu estava seguindo a ER, ou seja, tive que alterar o meu software para utilizar apenas a mensagem suplementar (promocional), assim como a primeira mensagem deste post criado por mim. Não adiantou em nada argumentar, mostrar o ato cotepe que rege as regras do ECF, onde mostra a disposição da mensagem suplementar e complementar, não adiantou mostrar que era o software básico do ECF Bematech que adicionava "Aplicativo:"... por fim, com isso só perdi tempo e a paciência... cheguei a conclusão que deve ser feito aquilo que o homologador está pedido, certo ou errado... senão seu sistema não é homologado. Fica aí o alerta para o pessoal. Abraço a todos, Fabrício Gomes Araújo

Realmente se utilizar formas de pagamentos distintas no ECF faz sentido ter mais de um CCD, entendi Régys. Obrigado. Homologuei TEF a menos de um mês, só que no meu caso utilizo apenas uma forma de pagamento com a soma dos cartões (Ex: Amex 1,00 e Redecard 3,00, então forma de pagamento: Cartao 4,00), então coloco tudo em um único CCD. Nunca tive problemas com a homologação tratando dessa forma. Mais uma vez obrigado pelas explicações. Fabrício Gomes Araújo

Colegas... me desculpem a ignorancia... mas para homologar TEF eu não tenho que ter apenas 1 CCD com todas as vias dos cartões TEF? Ou existem as duas opções? Fabrício Gomes Araújo

Daqui a pouco a Receita vai colocar as imagens distorcidas como o capcha da consulta para a galera não conseguir interpretar via sistema... Agora seria o momento de concientizar os clientes, mas vi que muitos estão interessados e m deixar o RecuperarXML funcionando com um XML não fiscal. Caso desse certo de Recuperar o XML como um serviço disponibilizado pela Receita seria ótimo, assim todos teriam o arquivo totalmente fiscal. Mas aí tem a questão do certificado de quem só recebe... O jeito é o cliente exigir do forncedor, afinal é lei. Fabrício Gomes Araújo