BigWings

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.

Corrigindo, o nome do componente é ACBrNFeDANFCeFortesA4, marcando o pacote ACBr_NFeDANFeRL.dpk ele deve ser instalado.

Usando o Fast Report, na pasta Obsoletos estão os arquivos onde não já é dado manutenção há algum tempo. Nada impede de você continuar usando, fazer uma cópia para si... Para usar o componente ACBrDANFCeFortesFrA4 você precisa do Fortes Report instalado e do pacote DANFE para Fortes Report marcados na instalação.

Tem o Fortes Report instalado? Instalou o pacote DANFE em Fortes? Tem a opção em Fast carregando o DANFeNFCeA4.fr3.

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.

Simples, remova essa dependência, gere o número localmente. O uso de série diferente em cada caixa é justamente pra não depender de um centralizador para a numeração.

Veja se não incluiu sem querer uma segunda nota no componente, isso geralmente causa esse erro. Procure por chamadas a NotasFiscais.Add.

Não. Apenas no CTe-OS (modelo 67) e no CTe multimodal. Para o modelo 57 normal os dados da seguradora devem ser informados no MDFe.

Veja:

Correção enviada para o repositório, rev. 16249. Favor atualizar novamente.

Veja a observação na regra de validação da NT 2017.002 v1.10: Como você está informando finNFe = 4 (devolução), o percentual de partilha para a UF de destino deve ser definida conforme a emissão da NFe referenciada. Se a NFe referenciada foi emitida em 2018, você deve informar a tag pICMSInterPart = 80. (80% em 2018, 100% em 2019).

Obrigado por reportar. Para o novo problema abra novo tópico.

Quando a origem da mercadoria (1º dígito do CST do ICMS) indica um item importado, com código de origem 1, 2, 3 ou 8, a alíquota do ICMS interestadual deve ser 4%.

Leia:

A classe ConsNFeDest, assim como a DownloadNFe foi removida dos fontes, já que já foi desativada há anos. Não encontrei nenhuma referência a propriedade retDistDFeInt.indCont. Qual era a revisão dos fontes que tinha antes da atualização?