BigWings

Consegue simular o erro usando o programa exemplo do ACBrNFe?

Não, o evento só precisa existir.

Veja que o caminho está para um local de rede. Isso pode acontecer se você tiver configurado dessa forma explicitamente, ou estar executando o ACBrMonitorPLUS de um local da rede. Se o path dos schemas estiver da mesma forma, e estiver usando LibXML2, terá o erro de schema inválido.

Limitação da LibXml2, o path dos schemas não pode ser no formato UNC (\\servidor\compartilhamento). Precisa mapear para uma unidade local ou usar links simbólicos.

Sim, se está havendo a alteração do tomador, o CTe original deve possuir o evento de prestação em desacordo, emitido pelo tomador do serviço para o qual foi gerado incorretamente.

Dos atores do CTe, o único que pode ser alterado é o tomador, e ele deve ser um dos já informados no CTe original. Os demais atores (destinatário, remetente, recebedor, expedidor) devem ser informados da mesma forma que no original.

Precisa corrigir, gerar novamente o XML, assinar, validar, enviar o XML completo... O que destaquei antes são os campos que formam a chave, se você mudar algum desses campos, a chave muda. Campos que formam a chave de acesso: CNPJ do emitente, data e hora de emissão, modelo, série e número da nota, código numérico (cNF), tipo de emissão (tpEmis).

O NCM do item não altera a chave de acesso. Então basta gerar novamente o XML corrigindo apenas a informação que causou a rejeição, no caso o NCM, e enviar. Mantendo todos os demais dados, data e hora de emissão, código númerico (cNF), tipo de emissão como contingência...

Você pode estudar os fontes do ACBrMonitor, ele está disponível em ACBr\Projetos. Pra carregar pelo ini basta chamar ACBrNFe.NotasFiscais.LoadFromIni, a partir daí chamar os métodos pra assinar, validar, enviar...

A questão acima já foi respondida em outro tópico. Vou encerrar este.

Tente a função reply-to: ACBrMail1.AddReplyTo('[email protected]'); // opcional

Tem a opção "Distribuição Documentos Fiscais", esse é o método disponibilizado pela SEFAZ pra download dos XML. Leia a NT 2014.002 que trata do assunto, para entender como funciona: https://www.nfe.fazenda.gov.br/portal/exibirArquivo.aspx?conteudo=ytucIh9FMb0= Alguns pontos principais: - Os XML ficam disponíveis por 90 dias após a autorização. - O emitente da nota não tem acesso, afinal ele já tem o XML. - Pra obter o XML completo, o destinatário deve enviar o evento de manifestação. - Os XML não são entregues em tempo real, é preciso aguardar o webservice estadual sincronizar com o Ambiente Nacional, e este gerar os NSU com os arquivos. - O programa exemplo do ACBrNFe do print já é antigo, veja se está com os fontes atualizados.

Você define a pasta para gravar os eventos na propriedade ACBrNFe.Configuracoes.Arquivos.PathEvento. Dentro dessa pasta você tem a opção de separar por CNPJ, Mes, Ano, Dia... O ACBr vai criar as pastas automaticamente de acordo com a configuração.

Sim. O componente já grava o XML do evento completo com o nome *-procEventoNFe.xml. Só precisa estar ativada a configuração para salvar arquivos.

Não tem diferença no método, apenas quando você carrega o XML o ACBr pode preencher o número do protocolo com os dados do arquivo, enquanto no cancelamento por chave você deve informar o protocolo explicitamente. Tem também uma opção pra atualizar o XML após o cancelamento com o cStat de cancelado, isso hoje não é o correto, pois está alterando o XML, mas alguns ainda usam por comodidade na integração com softwares contábeis.

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

Geralmente quando o código fonte no debug se comporta diferente é porque está na verdade executando um .dcu compilado com outra versão do fonte. Mas fica difícil sem conseguir replicar no exemplo, você tentou no exemplo informar as mesmas datas que na sua aplicação?

Veja: https://projetoacbr.com.br/fontes/

Tente reinstalar o ACBr marcando a opção de apagar arquivos antigos.

Esse bloco de código está dentro de um WITH o que dificulta o debug, o DT_FIN aí pode não ser o mesmo DT_FIN que está sendo processado. Consegue replicar o erro usando o programa exemplo?

Isso vai permitir que o Delphi grave os .dcu na pasta "Arquivos de Programas". Válido, mas não é o ideal, na minha opinião.

Aparentemente a modalidade já é incluída como parte da carteira para impressão. Na unit ACBrBoletoFCFR.pas: Field_Carteira.AsString := Banco.MontarCampoCarteira(ListadeBoletos[Indice]); Na unit ACBrBancoBrasil.pas: function TACBrBancoBrasil.MontarCampoCarteira(const ACBrTitulo: TACBrTitulo ): String; begin Result := IfThen(ACBrTitulo.ACBrBoleto.Cedente.Modalidade = '', ACBrTitulo.Carteira, ACBrTitulo.Carteira + '/' + ACBrTitulo.ACBrBoleto.Cedente.Modalidade ); end; A minha sugestão é alterar o FR3 deixando apenas [Titulo.Carteira] nesse campo. Atenção que isso pode interferir na impressão do boleto para outros bancos.

O que está informando para Titulo.Carteira?

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

Não entendi a dúvida, parece tudo correto. O cStat 138 indica que houve documento encontrado com o NSU ou chave da NFe informadas. No caso houve retorno de uma nota na tag docZip, pelo schema é o XML completo da nota, com NSU 48. O conteúdo do XML vem compactado e em base64 mas o componente já faz a extração. Exemplo de código: NFE.DistribuicaoDFePorChaveNFe(UFtoCUF(UF), CNPJCPF, ChaveNFe); if (NFE.WebServices.DistribuicaoDFe.retDistDFeInt.cStat = 138) and (NFE.WebServices.DistribuicaoDFe.retDistDFeInt.docZip.Items[0].schema = schprocNFe) then begin GravarXMLNoBD(ChaveNFe, NFE.WebServices.DistribuicaoDFe.retDistDFeInt.docZip.Items[0].XML); Inc(qtdDownload); end