BigWings

Faça teste usando o demo do ACBrNFSe e caso o problema ocorra nele informe o passo a passo para que possamos reproduzir.

Já foi feito um ajuste nos fontes do ACBr para contornar o problema do retorno fora do padrão. Está com os fontes atualizados?

Na opção "Mostrar original" do gmail, veja a parte de anexos:

Me parece que a geração do CNAB400 para esse banco ainda não foi validada. No tópico onde foi anexada a contribuição que foi enviada ao repositório não menciona a implementação do CNAB400, e comparando os códigos fontes está quase idêntico ao CNAB400 do Banco do Brasil. Se você quiser fazer as modificações necessárias de acordo com o manual do banco, basta abrir o arquivo ACBrBancoCredisis.pas e implementar/corrigir os métodos GerarRegistroHeader400 (header), GerarRegistroTransacao400 (detalhe e opcional) e GerarRegistroTrailler400 (trailler). Ou usar CNAB240 para a geração que aparentemente foi validada.

Não me parece o melhor lugar pra essa configuração. Enviei uma correção para o repositório, rev. 16584. Experimente testar novamente com o arquivo do repositório.

Esse tipo é inválido para NFCe. Use teNormal ou teOffline.

Obrigado por reportar. Fechando. Para novas dúvidas, criar um novo tópico.

O mesmo problema ocorre usando o demo do ACBrNFe?

Não tem opção para desativar a geração da linha, está fixo nos fontes. O registro tipo 5 contém os dados da multa, que é prática comum em boletos, porque quer remover?

Para dúvidas sobre o DistribuicaoDFe abra novo tópico (ou faça busca no fórum). Favor manter o assunto do tópico, para outras questões abra novo tópico detalhando o problema.

Fiz essa mesma alteração e aparentemente funcionou. Qual erro teve?

Estranho, esse método já faz a chamada do ACBrMail.AddAttachment com o parâmetro Disposition como adAttachment. Você verificou o fonte original do email para ver se o anexo está realmente como inline? Talvez tenha alterações locais aí, é preciso usar o debug pra saber.

Conforme a Nota Técnica 2014.002, os serviços NFeConsultaDest e NFeDownloadNF foram desativados em 31/05/2017 e substituídos pelo método DistribuicaoDFe. Por isso as referências aos primeiros foram removidos dos fontes. Sugiro a leitura da NT e a busca no fórum que já tem inúmeros tópicos sobre a DistribuicaoDFe.

Veja:

O gmail pode estar identificando o XML como corpo do e-mail. Se você usa o componente ACBrMail diretamente para envio veja se está informando o parâmetro Disposition, ele por padrão é adInline o que pode confundir o cliente de email. Caso use o método EnviarEmail do ACBrNFe ele já deve ir dessa forma.

Se está usando ESC-POS precisa configurar a impressora na "aba" PosPrinter. Lembrando que para a Elgin i7 e i9 você define o modelo como ppEscPosEpson. para a Elgin Vox informe ppEscVox.

Recomendo o uso do DACTE_Ve300.fr3 que tem alterações desde a versão 3.00 do CTe, como as informações do CTe globalizado e remoção dos dados do transportador. Mas mesmo com esse arquivo quanto com o DACTE.fr3 não percebi o problema: Percebi o problema usando o DACTE_RETRATO.fr3 e DACTE_PAISAGEM.fr3. Faça teste novamente usando os arquivos .fr3 do repositório.

Qual .fr3 está usando?

Seria melhor verificar o motivo de não estar carregando a URL correta. Pelo trecho de código que postou, a tua alteração não leva em conta o tipo de emissão por exemplo. O QRCode é diferente se tipo normal ou contingência off-line. O ACBr pega a URL do arquivo ACBrNFeServicos.ini, que também é compilado como ACBrNFeServicos.res, este último agregado no .exe da aplicação como recurso. No arquivo ACBrNFeServicos.ini estão configuradas as URL para MG, homologação e produção. [NFCe_MG_P] [...] URL-QRCode_2.00=https://nfce.fazenda.mg.gov.br/portalnfce/sistema/qrcode.xhtml URL-ConsultaNFCe_2.00=http://nfce.fazenda.mg.gov.br/portalnfce [NFCe_MG_H] [...] URL-QRCode_2.00=https://nfce.fazenda.mg.gov.br/portalnfce/sistema/qrcode.xhtml URL-ConsultaNFCe_2.00=http://hnfce.fazenda.mg.gov.br/portalnfce Se os teus fontes estão atualizados pode ser que o linker do Delphi esteja encontrando algum arquivo desatualizado. Atualize os fontes e execute novamente a instalação pelo ACBrInstall_Trunk2.exe, usando a opção de remover arquivos antigos do disco. Veja também se existe um arquivo ACBrNFeServicos.ini desatualizado no diretório da aplicação.

Não existe NFCe de entrada. Se no seu XML protocolado está correto, não tem muito o que se preocupar. Pode ser um erro na página de consulta da SEFAZ, entre em contato com eles e reporte o problema.

Na verdade tem em todos os componentes para impressão NFCe (ACBrNFeDANFeEscPOS, ACBrNFeDANFCEFR, ACBrNFeDANFCeFortes, ACBrNFeDANFCeFortesA4). Como a propriedade ACBrNFe.DANFE recebe uma classe em parte abstrata, pode ser feito um typecast para definir o tipo do componente DANFE vinculado. if (ACBrNFe.DANFE is TACBrNFeDANFCEClass) then TACBrNFeDANFCEClass(ACBrNFe.DANFE).ViaConsumidor := True; Também precisa ser feito via código, não é uma propriedade disponível no Object Inspector.

Que saiba o valor total dos acréscimos (frete, seguro e outras despesas) já é impressa no DANFE NFCe.

Verifique se está configurando a versão correta no componente: ACBrNFe1.Configuracoes.Geral.VersaoDF := ve400;

Veja o vídeo abaixo:

Não confunda o número da remessa com o nosso número do boleto. Cada remessa pode conter vários títulos, mas a numeração de cada arquivo de remessa deve estar em sequência de acordo com a última remessa enviada ao banco. A rejeição informada no arquivo de retorno é por causa disso: Você informar o número da remessa para o componente desta forma: ACBrBoleto1.NumeroArquivo := <numero_remessa>;