BigWings

Me parece que essa "artimanha" usada para validar o arquivo deixou de funcionar a partir deste ano.

Para NFe de emissão própria você não deve informar o registro C170. Caso informe, deve obrigatoriamente informar também o C176.

Se está usando o componente para Fast Report você deve agora usar o componente específico para NFCe:

@jmcsoftware @fusina245 Correção aplicada no repositório, rev. 16334. Favor atualizar os fontes e testar novamente.

Qual IDE e versão está usando?

Como está passando a string do parâmetro? Com ACBrNFe1.NotasFiscais.LoadFromFile funciona? Testei pelo demo e não tive erro.

O que diz o campo "Modalidade do frete" na consulta da NFe no portal nacional? Lembre-se que o DANFE é apenas um documento auxiliar e não a nota em si. Que me consta não existe essa modalidade, e esse DANFE está fora das normas técnicas da NFe.

select i.codvend , w.vlrtotal soma_venda , sum(i.vlrtotal) soma_item from tab_item i left join tab_vend w on (w.codvend = i.codvend) where w.datvend>=:dae group by i.codvend, w.vlrtotal having sum(i.vlrtotal) > w.vlrtotal

O cNF (código numérico) deve ter no máximo 8 dígitos: Para a chave 23190124854238000142550010000002281524745605 o cNF é 52474560, o último caractere é o dígito verificador da chave.

@luispalladino Atualize os fontes e teste novamente.

Se você tem a Jedi instalada pode tentar debugar o instalador, na pasta ACBr\Projetos\ACBrInstall_Trunk2, e ver em que ponto está ocorrendo a lentidão.

Use ACBrNFeDANFEFR1.MostraSetup.

Fiz o mesmo teste, na mesma versão do ACBrMonitorPLUS e o e-mail foi gerado com o Content-Disposition: attachment normalmente. Gerar como inline pode ocorrer se estiver com uma versão anterior a junho de 2018, que foi quando o ajuste no método EnviarEmail do componente foi feito. https://sourceforge.net/p/acbr/code/15362/ Qual comando do ACBrMonitorPLUS está usando para o envio do email?

Em quais pacotes esse erro acontece? Uma outra forma é adicionar manualmente "Vcl" a Project - Options - Delphi Compiler - Unit scope names. A forma mais adequada, acredito, é incluir a dependência no dpk que já faz o acima por padrão. Experimente com o arquivo anexo. ACBr_NFeDanfeFR.dpk

Nâo é possível, nem necessário inutilizar numeração de MDFe.

Pelo que entendi da documentação: - Está restrito aos emitente do RS - Apenas o contabilista tem acesso a esse serviço, com o certificado do próprio emitente não é possível consumir os webservices.

Eu também tinha entendido que era algo relacionado ao infAdProd por isso perguntei sobre a propriedade. No seu caso a versão do Fast Report que vem junto ao Delphi não tem suporte a scripts por isso apenas os arquivos .fr3 identificados como "Basic" na pasta Obsoletos são compatíveis. Você pode instalar a versão profissional do Fast Report, usar os arquivos "Basic" ou ainda mudar para o DANFE em Fortes Report.

Correto. O XML retornado pela SEFAZ-MG está fora do padrão definido nas Notas Técnicas. Em outro tópico já foi reportado esse problema:

Essa versão não suporta os arquivos do repositório, você precisa atualizar para a versão 5.x.

Correção enviada ao repositório, rev. 16276, fiz um ajuste adicional na largura do subreport para mais clareza. Obrigado pela contribuição.

Esse é um problema recorrente da SEFAZ-MG.

Pode por favor anexar um XML com a composição de frete para verificar o antes e depois?

Isso não tem a ver com o componente, e sim com a função StrToInt que gera esse erro caso não se informe um número inteiro válido como parâmetro. Então o campo COD_MUNICIPIO_IBGE no seu dataset deve estar em branco. Experimente trocar pra StrToIntDef().

Existem mais condições para a impressora decidir imprimir em uma linha apenas. Do manual da Bematech MP-2100 TH FI: Caso você desabilite essa configuração na impressora (acredito que o ACBrECF não encapsule essa configuração), será impresso sempre em duas linhas.

Mesmo na revisão do dia 09/11 não existe a propriedade indCont para a classe TRetDistDFeInt. O indicador de continuidade para o método DistribuicaoDFe é feito através do cStat de retorno, e não uma tag no XML como era no ConsultaNFeDest. Talvez você quis dizer TRetConsNFeDest.indCont, que tratava o retorno do método ACBrNFe.ConsultaNFeDest, esta classe foi removida. Improvável, o código dos métodos ACBrNFe.ConsultaNFeDest e ACBrNFe.DownloadNFe já estavam gerando exceção se chamados, desde 05/2017: function TACBrNFe.ConsultaNFeDest(CNPJ: String; IndNFe: TpcnIndicadorNFe; IndEmi: TpcnIndicadorEmissor; ultNSU: String): Boolean; begin // Desativar o acesso a esse serviço após 02/05/2017 Result := False; GerarException('Após 02/05/2017 o Web Service ConsultaNFeDest foi desativado pela SEFAZ.'+#13+ 'Favor utilizar o método DistribuicaoDFe.'); É possível que o código que está causando erro de compilação nem estivesse mais sendo usado pela sua aplicação por isso você não percebeu.