BigWings

No trecho de código não consta o envio da manifestação. Para enviar a manifestação você usa o método ACBrNFe.EnviarEvento, informando no tipo de evento qual a manifestação está sendo feita. Isso deve ficar a critério do operador, uma manifestação incorreta pode trazer problemas pra empresa ou pro emitente da nota. Após a manifestação é preciso aguardar o Ambiente Nacional processar e gerar novo NSU com o XML completo da nota, isso pode demorar. Enquanto o AN não gerar o NSU com o XML completo, no retorno do método DistribuicaoDFePorChaveNFe vai ser retornado apenas o resumo da NFe. Se você usar os métodos DistribuicaoDFePorNSU e DistribuicaoDFePorUltNSU podem ser retornados o resumo da nota, a nota completa, o resumo do evento e o evento completo. Você pode testar o tipo de documento que está sendo retornado pela propriedade ACBrNFe.WebServices.DistribuicaoDFe.retDistDFeInt.docZip.Items[ x ].schema. Sugiro que leia com atenção a Nota Técnica que trata do assunto: https://www.nfe.fazenda.gov.br/portal/exibirArquivo.aspx?conteudo=ytucIh9FMb0=

O webservice devia rejeitar a NFCe se informar a URL errada... Veja se o arquivo ACBrNFeServicos.ini está atualizado.

A SEFAZ retorna os documentos compactados e convertidos em base64. O componente faz o trabalho de descompactar e converter de volta, fica disponível o XML pronto, e também salvo em disco caso esteja configurado pra isso.

Tente configurar no componente DANFE a propriedade ExibeInforAdicProduto = infSeparadamente.

Não consegui identificar nada. Edite a imagem e destaque qual parte está errada.

Seja mais claro, o que está "desconfigurado" no DANFE? Se for o código do produto imprimindo sobre a descrição, você pode aumentar a largura da coluna na configuração.

A mensagem indica um bloqueio na sua caixa de emails, por excesso de emails enviados. Não creio que tenha como validar isso no componente.

Em formato de tabela, não conheço, no ACBr está implementado no código. O ACBr gera os alertas na geração do XML com base no layout, esses alertas são exibidos na validação, é o que aparece em cima na mensagem. Já a última linha é a validação contra os arquivos de schema, isso é feito pela DLL (libxml2, msxml). Você também pode usar a ValidarRegrasDeNegocios para prever as regras de validação da SEFAZ que podem causar rejeição. Tudo está disponível nos manuais da NFe: https://www.nfe.fazenda.gov.br/portal/listaConteudo.aspx?tipoConteudo=33ol5hhSYZk=

Para a referência ao ACBr, veja as propriedade "Sistema" e "Site" do componente do extrato. As demais informações vem do XML do CFe.

Sim, só precisa compatibilizar com as versões antigas do Delphi que não tem essa propriedade.

Tem algo errado na chamada a ARemessa.Count no seu ambiente, não consegui replicar o problema aqui no Delphi/Windows. Em cada interação são adicionadas duas linhas então se na primeira interação ARemessa.Count é 1, na segunda vai ser 3. Tente alterar a linha: wLinha:= wLinha + sLineBreak + Para: wLinha:= wLinha + aRemessa.LineBreak + E veja se resolve.

Não devia duplicar já que está inserindo duas linhas de cada vez, com o uso de sLineBreak pra separar. Qual sua IDE? Está compilando para Windows ou Linux?

Pode sim exigir o XML válido, esse XML sequer valida pelos schemas:

Esse erro invariavelmente é por informar o IdCSC ou CSC incorretos. Não, pra gerar o QrCode no XML e no DANFe NFCe é preciso gerar o hash.

Nas configurações para NFCe do ACBrMonitorPLUS, além do CSC e IdCSC, informe a versão do QrCode "2".

Pelo que testei o problema é o I maiúsculo no início. Se informar a tag do grupo como infRespTec em vez de InfRespTec deve funcionar.

Para o emitente do MDFe não é retornado o XML, afinal ele já tem o arquivo, e pode disponibilizar o XML de outras formas, enviando por email por exemplo. Para a NFe está sendo implantado o evento de "Ator interessado" que vai permitir que o transportador receba o XML da NFe pelo método DistribuicaoDFe da NFe. Já para CTe não tem nada nesse sentido.

O XML de resumo da NFe só é retornado para o destinatário da nota, considerando o CNPJ informado na consulta. Pra saber qual a IE seria necessário primeiro enviar a manifestação, pra assim obter o XML completo. Tendo o XML completo, você pode carregar ele no componente e comparar a IE do destinatário.

Serve pra justamente isso, mas não é correto. Isso vem da versão antiga da NFe, quando ainda não existia o cancelamento por evento, e ainda é mantido para permitir integração principalmente com contabilidade que não consegue (ou não quer) importar os XML de cancelamentos pra atualizar a situação das NFe.

No serviço DistribuicaoDFe do MDFe não são retornadas as chaves dos documentos, por razão de sigilo fiscal. Veja o que diz a NT 2015.002:

A propriedade "FormularioContinuo" está ativada no componente? Veja também a configuração de tamanho de papel no driver da impressora. Outra solução, mais indicada, é usar EscPos.

Pela documentação, webservice e schemas disponibilizados pela receita, não é retornada essa informação.

Qualquer serviço se executado em loop recebendo o mesmo retorno pode causar rejeição por consumo indevido. Não é algo com o certificado? Se você descarregar o certificado e carregar novamente, em vez de destruir o componente, funciona?

Cada banco tem a sua rotina de homologação. Eles não homologam o sistema, a homologação é feita pra cada cliente que for iniciar o uso de emissão de boletos por sistema próprio.

Esse pacote não existe mais na repositório... tente remover ele do seu Lazarus.