BigWings

Não tem erro na função. A exceção está correta, o problema é você estar informando o cNF (Código numérico) da nota igual ao nNF (Número) da NFe. Desde a NT 2019/001 isso não é mais permitido. Sugiro a leitura do tópico abaixo:

Isso pode ter sido causado por problemas na restauração. Quando há problemas e o FB não consegue criar os índices, por exemplo, quando há registros faltando, ele deixa o banco de dados em modo "shutdown" que é de manutenção, por isso apenas uma conexão pode ser feita nele. Essa situação é informada no log da restauração, se você não marcou a opção "verbose" na restauração não conseguiu ver essa mensagem. Antes de retornar o banco para "online" como sugerido pelo Rafael você deve verificar os problemas. Para verificar índices inativos: C:\Temp>"c:\Program Files (x86)\Firebird\Firebird_2_5\bin\isql.exe" banco.fdb -user sysdba -pass masterkey Database: banco.fdb, User: sysdba SQL> select rdb$index_name from rdb$indices where rdb$index_inactive = 3; Caso retorne algo você pode tentar reativar cada índice, desta forma: SQL> alter index idx_meu_indice active; O mais provável é que ainda ocorra erro por ser um índice de chave estrangeira onde está faltando registros, então para ativar o índice você vai precisar restaurar o registro com problema, ou se não for possível, apagar os registros que referenciam o mesmo. Após isso tentar ativar o índice novamente. Depois de ativar todos os índices você pode colocar o banco em modo "online" novamente. C:\Temp>"c:\Program Files (x86)\Firebird\Firebird_2_5\bin\gfix.exe" -online banco.fdb -user sysdba -pass masterkey

O CFe pode ser referenciado na tag NFref.refNFe. Para cupom fiscal ECF referencia-se no grupo NFref.refECF.

Aparentemente está acessando uma URL que não existe mais, por ser de versão antiga. Então verifique as configurações de versão do componente: ACBrNFe1.Configuracoes.Geral.VersaoDF := ve400; ACBrNFe1.Configuracoes.Geral.VersaoQrCode := veqr2000;

Qual foi exatamente o código e mensagem de rejeição? A rejeição 704 - "NFC-e com data-hora de emissão atrasada" só deve acontecer com NFCe emitidas no modo normal. Para NFCe emitida em contingência a NFCe deve ser autorizada, após o prazo de 24 horas, com o cStat 150 - Autorizado fora do prazo. Então certifique-se que a NFCe sendo transmitida está com o campo tpEmis = 9 (Contingência off-line) e não 1 (Normal).

Qual delas está marcando como True? Qual o resultado que espera e como está sendo gerado? Se apenas SepararPorAno estiver marcada será gerado: ...\2019 Se SepararPorAno e SepararPorMes estivererem marcadas: ...\2019\07 Se SepararPorAno, SepararPorMes e SepararPorDia estiverem marcadas: ...\2019\07\03 Se apenas SepararPorMes estiver marcada: ...\201907 Se SepararPorMes e SepararPorDia estiverem marcadas: ...\201907\03 Se apenas SepararPorDia estiver marcada: Parece que aqui pode ter um bug, não será gerada separação por dia... não vai acontecer porque o componente não permite marcar apenas SepararPorDia.

Não é impossível se você armazenar o código numérico da NFe em banco de dados, da mesma forma que já armazena o número, data de emissão e os demais dados necessários para compor a chave de acesso. Usar cNF = nNF + 1 o emitente fica vulnerável a acesso indevido em suas NFe e possibilitando fraudes, da mesma forma que usando cNF = nNF.

Veja a própria regra que você citou, o cNF (Código Numérico da NFe) não pode ser igual ao nNF (Número da NFe). O código numérico deve ser um número aleatório. Se for igual pode ser este o motivo da rejeição, caso contrário é erro na SEFAZ. Veja no tópico que anexei outros usuários do fórum com o mesmo problema.

Provavelmente é um erro da SEFAZ em retornar a mensagem de rejeição correta. Você verificou o cNF e nNF se estão diferentes?

Você tem razão, o correto é 50. O código IBGE de Campo Grande - AL me levou a esse equívoco.

Tente informar o comando desta forma: CTe.DistribuicaoDFePorUltNSU("27","26770818000268","0")

Quer dizer que o XML está sem o protocolo de autorização.

Como foi gerado esse XML que você está tentando consultar? Pode anexar ele aqui?

Já testou pelo demo do ACBrNFe? Já testou informando o valor diretamente no código?

Depende do que você quer fazer.

Está informando algum valor para a tag compra.xPed? Fiz teste apenas preenchendo o campo no demo do ACBrNFe e o grupo e tag foram gerados normalmente. Talvez tenha algo errado na sua rotina.

Pode confirmar qual a URL correta?

Na pasta ACBr\Exemplos\ACBrDFe\ACBrMDFe tem um.

Veja que para a rejeição 878 você deve verificar a URL de consulta por chave de acesso e não a URL da consulta por QRCode. De fato há uma discrepância entre as URL de consulta em homologação. - Segundo o informado na página do ENCAT: http://nfce.encat.org/consulte-sua-nota-qr-code-versao-2-0/ Você deveria ter no arquivo ACBrNFeServicos.ini: [NFCe_MG_H] ... URL-ConsultaNFCe_2.00=http://hnfce.fazenda.mg.gov.br/portalnfce/ - Já de acordo com a página da SEFAZ-MG: http://www.sped.fazenda.mg.gov.br/spedmg/nfce/web-services/ Deveria constar no .ini: [NFCe_MG_H] ... URL-ConsultaNFCe_2.00=http://hnfce.fazenda.mg.gov.br/portalnfce Para produção não vi diferença entre as URL informadas na SEFAZ e ENCAT.

Experimente desmarcar a configuração "Expandir logo".

Verifique se o Fortes Report está instalado corretamente.

Veja que a sua rejeição foi diferente. Se você validar o teu XML no validador da SEFAZ-RS verá que realmente tem algo errado com a nota, neste caso o problema não é a SEFAZ.

O que não sai são os dados do emitente ou do destinatário da nota? Não vi nada de errado no XML. Anexe o PDF do DANFE.

Se o CNPJ da transportadora está informada no XML da NFe no campo referente ao CNPJ da transportadora, ou como terceiro na tag autXML ela vai receber o XML da NFe automaticamente pelo método ACBrNFe.DistribuicaoDFe. Já caso ela queira os conhecimentos de transporte você precisa usar o ACBrCTe.DistribuicaoDFe.

Realmente as configurações de margem do componente não são respeitadas, por hora é preciso alterar diretamente no .fr3.