BigWings

Se você olhar o manual, nas espécies aceitas não tem o DSI. Creio que vai precisar informar como "DS".

Qual o banco?

Primeiro, precisa enviar o evento com a manifestação da nota e aguardar ser gerado o novo NSU com o XML completo que pode demorar. Depois executar novamente o DistribuicaoDFePorUltNSU, DistribuicaoDFePorNSU ou DistribuicaoDFePorChaveNFe. Usar o DistribuicaoDFePorNSU não fica prático nesse cenário porque você tem que informar o NSU do XML completo e não o NSU do resumo.

Esse retorno apenas com "0" foi corrigido há muito tempo já... Está com os fontes atualizados?

Enviei um ajuste para o repositório para esta situação, rev. 21266. O valor líquido agora será impresso apenas uma vez:

Isso é rejeição da SEFAZ ou erro do componente? Se for do componente e estiver enviando um evento apenas com a chave precisa limpar as notas primeiro, com ACBrNFe.NotasFiscais.Clear.

O componente salva os arquivos assim que é executado o método ACBrNFe.DistribuicaoDFe. Pra gravar precisa configurar: - ACBrNFe.Configuracoes.Arquivos.Salvar := True; - ACBrNFe.Configuracoes.Arquivos.DownloadDFe.PathDownload := <caminho pra gravar as NFe>; - ACBrNFe.Configuracoes.Arquivos.PathEvento := <caminho pra gravar os eventos>;

Se você compila ele, sim, basta abrir o pacote ACBr_NFe_DANFeRL do componente no Lazarus e fazer as alterações, reinstalar o pacote, e recompilar o ACBrMonitorPLUS. Se usa ele já compilado, não.

O que quer dizer com "nunca vem nada"? DocZipItem fica nil? Tem erro de "index out of bounds"?

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.

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.

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: