BigWings

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.

Boletos maiores que 100,00 poderão ser pagos em qualquer banco a partir de 13/10/2018. No momento, apenas os boletos acima de 400,00.

Veja que configurou a pasta de schemas usando o formato UNC: PathSchemas=\\192.168.2.13\bin\NFe\Schemas Dessa forma causa o erro "Schema inválido" usando xsLibXML2 ou "The schema itself is not valid" usando xsXmlSec. Isso é limitação da libxml2.dll. Para resolver, você pode alterar para xsMsXML (não recomendado) ou copiar os schemas para uma pasta local, ou ainda apenas mapear a unidade de rede para uma letra de unidade local.

Se a NFCe foi autorizada sim. Mas recomendo que entre em contato com a SEFAZ para comunicar o problema. E continue usando o QRCode na versão 1.0, ou insira essa opção como parametrizável. Já que o consumidor que receber a NFCe vai ter o erro na hora de fazer a consulta e isso trazer transtorno para a empresa.

Algum erro na página de consulta da SEFAZ.

Fez alguma alteração nos fontes do componente? Se fez anexe aqui para análise.

Para instalação, não, exceto no caso do componente para impressão da GNRE. Para utilização dos .fr3 disponíveis no repositório, como já dito, sim, eles são feitos para a versão 5 e não são compatíveis com a 4.

Sim. Repassei para os demais mantenedores. Mas de qualquer forma seria interessante você entrar primeiro em contato com a SEFAZ.

Você está com problema na instalação do FastReport. Sugiro que desinstale todas as versões, removendo as referências no library path do Delphi, e instale a versão 5.X comercial do FastReport, não esquecendo do FastScript. Feito isso rode a instalação do ACBr novamente.

A documentação não informa nenhuma forma de descobrir a situação atual da manifestação de uma NFe. Se o aplicativo da receita faz isso, desconheço como.