BigWings

O QRCode deve ser mostrado para o consumidor, seja na impressão do DANFE ou em tela para permitir que ele faça a consulta da nota. Se entendi bem, você esperava que aparecesse a imagem do QRCode na página de consulta da SEFAZ, isso não acontece, nem há necessidade.

Peça para o contador emitir a nota em homologação. Se autorizada, veja em qual exceção à regra ela se enquadra.

Essa regra foi alterada na versão 1.61 da NT. Ela agora aplica-se somente a NFCe. E como não existe NFCe sem pagamento, ou NFCe de ajuste ou devolução as exceções da regra não fazem sentido.

Analisando o código não encontrei base nas notas técnicas que suportassem a lógica usada. Subi para o svn minhas próprias correções de acordo com a NT para as validações. Favor atualizar os fontes e proceder com os testes.

Obrigado por reportar. Para novas dúvidas crie novo tópico.

Não foi gerado o arquivo LOG.txt após a execução do comando?

Anexe o log.

Segundo a NT 2016.002 v.1.61: Em relação a NFC-e, os prazos previstos são: - Desativação do versão 3.10 do leiaute da NFC-e: 01/10/2018; - Layout do QR-Code (tag: qrCode, Id:ZX02), versão “2.00”: - Ambiente de Homologação: 04/06/2018 (aceita NFC-e na versão 4.00 com o leiaute do QR-Code na versão “1.00” e versão “2.00”); - Ambiente de Produção: 02/07/2018 (aceita NFC-e na versão 4.00 com o leiaute do QR-Code na versão “1.00” e versão “2.00”); - Desativação da versão “1.00” do QR-Code em produção: 01/10/2018. O QRCode é gerado no XML, dependendo da tag tpEmis. A impressão no DANFE NFCe é feita de acordo com o XML.

MG? Veja o tópico:

O componente não faz esse tratamento. Mas analisando o demo da pasta ACBr\Exemplos\ACBrDFe\ACBrNFe\Delphi - TEF percebi que ele faz isso. procedure TForm1.finalizarCupomNFCe; var StrDescMensagem : string; begin travarComponentesTEF(False); if not(enviarNFCeTEF(EditNumNFCe.Text, StrDescMensagem)) {Tenta emitir a NFCe em Modo Normal}then begin Application.MessageBox(pchar('Ocorreu um erro ao enviar a NFCe em modo normal.' + sLineBreak + 'Sistema emitirá em modo "OFFLINE/CONTINGÊNCIA" ' + sLineBreak + '#Programador tratar sua aplicação para envio das NFCes emitidas off-line para SEFAZ Estadual' + sLineBreak + StrDescMensagem), 'Informação', MB_OK + MB_ICONERROR); GerarNFCeTEF(EditNumNFCe.Text, StringToFloatDef(EditTotalPago.Text, 0), True); O manual de especificações da contingência off-line da nfce diz que, havendo erro de comunicação no envio da NFCe normal, deve-se gerar uma nova numeração de NFCe, justamente para evitar que haja duas chaves e dois XML para a mesma NFCe. A numeração anterior onde houve a tentativa de envio deve ser marcada para ser cancelada ou inutilizada posteriormente. http://www.nfe.fazenda.gov.br/portal/exibirArquivo.aspx?conteudo=YbZEjEHCuHQ= Provavelmente quando o demo foi feito ainda não havia esse manual, ou quem implementou não seguiu a regra.

Cada XML tem um tpEmis diferente o que muda a chave da NFCe o que muda o nome do arquivo a gravar. Que saiba o demo não faz essa alteração, por favor, informe o passo a passo que levou a essa situação.

A leitura das tags do XML é case-sensitive, então se no teu XML está AutXML em vez de autXML provavelmente será ignorado pela rotina de carregamento.

Está no repositório, basta atualizar.

Testei consulta de um CNPJ do RS e está funcionando normalmente. Foi feito uma alteração recente no webservice que exigiu uma correção: Revision: 15592 Author: bigwings Date: segunda-feira, 20 de agosto de 2018 15:42:37 Message: 20/08/2018 -- ACBrNFeWebServices -- [*] Ajuste para serviço de consulta de cadastro NFe 4.00 RS e SVRS que tiveram o WSDL do serviço corrigidos. Por: BigWings Está com os fontes atualizados?

Qual UF?

Após fazer essa alteração, você recompilou/reinstalou o ACBr? Se não faça isso, de preferência marcando a opção de remover os arquivos antigos do disco.

Realmente, nem tinha testado mas o ACBrValidador indica sim o erro no prefixo: ACBrValidador1.TipoDocto := docPrefixoGTIN; ACBrValidador1.AjustarTamanho := True; ACBrValidador1.Documento := Edit1.Text; If NOT ACBrValidador1.Validar Then raise Exception.Create(ACBrValidador1.MsgErro); Retorna: Prefixo "190" do GTIN "1909405092896" informado inválido.

Isso é problema no webservice de MG. https://www.projetoacbr.com.br/forum/search/?q=unmarshalling error&search_and_or=and

O webservice faz consulta ao cadastro do GS1, coisa que o componente não tem como fazer... se o GTIN não for cadastrado vai ser rejeitado.

Veja o método DistribuicaoDFe, e os eventos de manifestação do destinatário.

Você tentou consultar a mesma chave? Pelo retorno o webservice que respondeu foi o SVAN, enquanto na sua primeira mensagem a URL era da SVRS. E continua tentando acessar o webservice da NFe 3.10 por isso o erro de cabeçalho do XML. Nenhum dos dois. A consulta de protocolo retorna apenas a situação e protocolo de uma NFe qualquer, não retorna o XML completo da NFe.

Nesse caso, verifique se está com os fontes atualizados, e se não há um arquivo ACBrNFeServicos.ini desatualizado no diretório do executável. A URL que aparece na mensagem de erro é da versão anterior da NFe, que já foi desativada.

Configurou a versão para 4.00?

Que saiba a emissão do MDFe é obrigatório em toda operação interestadual. Entendo que é justamente por isso que a informação dos veículos na NFe está sendo removida, e já foi removida no CTe.

No tópico citado o usuário não mencionou em nenhum momento se a nota era interna ou interestadual. Pela NT 2016.002 v1.61 a rejeição 868 é obrigatória para NFe interestadual e pode ser aplicada também em NFe interna, a critério da UF. Uma pergunta: Está sendo emitido o MDFe com os dados dos veículos e vinculado a NFe? Se mesmo com o MDFe estão exigindo os dados dos veículos na NFe, a única solução seria informar nas informações complementares da nota.